Collaboration in Scrum

Collaboration in Scrum refers to the Scrum Core Team working together and interfacing with the stakeholders to create and validate the deliverables of the project to meet the goals outlined in the Project Vision. It is important to note the difference between cooperation and collaboration here. Cooperation occurs when the work product consists of the sum of the work efforts of various people on a team. Collaboration occurs when a team works together to play off each other’s inputs to produce something greater.

The core dimensions of collaborative work are as follows:

• Awareness—Individuals working together need to be aware of each other’s work.
• Articulation—Collaborating individuals must partition work into units, divide the units among team members, and then after the work is done, reintegrate it.
• Appropriation—Adapting technology to one’s own situation; the technology may be used in a manner completely different than expected by the designers.

Collaboration ensures that the following project benefits are realized:

1. The need for changes due to poorly clarified requirements is minimized.
2. Risks are identified and dealt with efficiently. For example, risks to the project are identified and assessed in the Develop Epic(s), Create Deliverables, and Conduct Daily Standupprocesses by the Scrum Core Team members. The Scrum meeting tools such as the Daily Standup Meeting, Sprint Planning Meeting, Prioritized Product Backlog Review Meeting, and so on provide opportunities to the team to not only identify and assess risks, but also to implement risk responses to high-priority risks.
3. True potential of the team is realized. For example, the Conduct Daily Standup process provides scope for the Scrum Team to collaborate and understand the strengths and weaknesses of its members. If a team member has missed a task deadline, the Scrum Team members align themselves collaboratively to complete the task and meet the targets agreed to for completing the Sprint.
4. Continuous improvement is ensured through lessons learned. For example, the Scrum Team uses the Retrospect Sprint process to identify what went well and what did not go well in the previous Sprint. This provides an opportunity to the Scrum Master to work with the team to rework and improve the team for the next scheduled Sprint. This will also ensure that collaboration is even more effective in the next Sprint.

Why Empirical Process Control is Important in SCRUM?

In today’s rapidly changing market trends, the customer may imagine an ‘apple’ and the finished product made by the project team may be an ‘orange’. This though is not the main problem. If the customer is aware of what’s cooking from the start he can steer the team to the ‘apple’ side. But in actuality the customer finds out about the ‘orange’ only too late. In other words if inputs and processes are in control and are reliable, we can get reliable outputs (which are generally the case with Waterfall model). The problem arises when inputs and processes cannot be controlled rigidly which generally means that the outputs would be unreliable (the Agile/Scrum scenario). In such circumstances we need to look beyond the waterfall model and focus on Empirical Process Control which simply means you need to look at the outputs more frequently and if it is not as per your liking you go back to inputs and processes and tweak it accordingly.

In Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning. Empirical process control relies on the three main ideas of transparency, inspection, and adaptation.

Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture. In Scrum we have a Project Vision Statement which can be viewed by all stakeholders and the Scrum Team; an open Product Backlog with prioritized User Stories, both within and outside the Scrum Team; clearly visible Scrumboards, Burndown Charts, and other information radiators; Daily Standup Meetings conducted making sure everyone’s aware of everything; and Sprint Review Meetings in which the Scrum Team demonstrates the potentially shippable Deliverables.

The following figure summarizes the concept of transparency in Scrum

Inspection in Scrum is depicted through the use of a common Scrumboard; collection of feedback from the customer and other stakeholders; review and approval of the Deliverables by the Product Owner and the customer.

The following figure summarizes the concept of inspection in Scrum:

Adaptation happens as the Scrum Core Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing. In Daily Standup Meetings, Scrum Team members openly discuss impediments to completing their tasks and seek help from other team members. Risk identification is performed and iterated throughout the project. Improvements can also result in Change Requests, which are discussed and approved. The Scrum Guidance Body interacts with Scrum Team members during many processes to offer guidance and also provide expertise as required. During the Sprint Retrospective, agreed actionable improvements are determined.

The following figure summarizes the concept of adaptation in Scrum:

These three pillars of Empirical Process Control ensure that the problems which projects face in the Traditional Waterfall way of doing things do not happen in Scrum Projects.

Agile User Stories

User Stories adhere to a specific, predefined structure and are a simplistic way of documenting the requirements and desired end-user functionality. A User Story tells you three things about the requirement: Who, What, and Why. The requirements expressed in User Stories are short, simple, and easy-to-understand statements. The predefined, standard format results in enhanced communication among the stakeholders and better estimations by the team.

The Product owners create User Stories which are designed to ensure that the customer’s requirements are clearly depicted and can be fully understood by all stakeholders. The Product Owner, based on his or her interaction with the stakeholders, business knowledge and expertise, and inputs from the team, develops User Stories that will form the initial Prioritized Product Backlog for the project. At times, the Product Owner may bring a Business Analyst to assist with writing User Stories.

How User Stories are created?

User Story Workshops  User Story Workshops are useful in understanding user expectations for the deliverables and are excellent for team building. They also facilitate preparation for the planning of the next Sprint. A User Story Workshop is a good platform to discuss and clarify every element of a product and often delve into the smallest details to ensure clarity. These workshops help the Product Owner to prioritize requirements and enable the Scrum Core Team to have a shared perspective of the Acceptance Criteria. They ensure that the Epics and User Stories describe the functionality from the users’ point of view, are easy to understand, and can be reliably estimated.
User Group Meetings
User Group Meetings involve relevant stakeholders (primarily users or customers of the product). They provide the Scrum Core Team with firsthand information about user expectations. This helps in formulating the Acceptance Criteria for the product and provides valuable insights for developing Epics. User Group Meetings are vital in the prevention of expensive rework that may result from a lack of clarity regarding expectations and requirements. These meetings also promote buy-in for the project and create a common understanding among the Scrum Core Team and relevant Stakeholder(s).
Focus Group Meetings
Focus Group Meetings are a qualitative technique to gauge and understand user needs and expectations about a proposed product. A small group of users are selected to form the focus group. This group may be selected randomly from a large pool of users or can be selected specifically to represent all the major Personas being targeted. Focus Group Meetings normally adhere to a certain format in which the group is asked questions that they then discuss among themselves. Each Focus Group Meeting can have its own rules of discussion as decided by the organizers. These meetings are usually held in the presence of a moderator.
User or Customer Interviews
Engaging stakeholders, including the sponsor, users, and customers of the product, is important to gain the necessary context and insight required to develop Epics. Quality time spent interviewing users and customers will result in ensuring that the requirements in Epics align with the overall Project Vision, thereby delivering greater value.
Questionnaires
A cost effective way to gain quantitative and qualitative statistical insight from a large number of users or customers is to use surveys or Questionnaires. A Questionnaire is a research instrument that contains questions to be asked to a respondent in order to collect information about a specific issue or topic. Questionnaires can be self-administered or administered by an interviewer. In conclusion, user stories are the best way to document the requirements from the end uses perspective. The Use Stories can be written in several ways but the basic aim of creating these User Stories is to understand the requirements of the end user and implementing them accordingly.
To read more interesting articles about scrum and agile, visit – www.SCRUMstudy.com/blog
Also for all latest updates and information on SCRUM follow @SCRUMStudy_ on Twitter

What is Epic in Agile Methodology?

What are Epics? User Stories may have to be written constantly throughout the duration of the project. In the initial stages of writing, most User Stories are high-level functionalities. These User Stories are known as Epic(s). Epic(s) are usually too large for teams to complete in a single Sprint. Therefore, they are broken down into smaller User Stories.

User Group Meetings

In the Scrum Methodology, User Group Meetings involve relevant stakeholders, (primarily users or customers of the product), and provide the Scrum Core Team with firsthand information about the expectations of the users. This helps in formulating the Acceptance Criteria for the product, and provides valuable insights for developing Epics. User Group Meetings are vital in the prevention of expensive rework, which may result from lack of clarity regarding expectations and requirements. These meetings also promote buy-in for the project, and create a common understanding among the Scrum Core Team and relevant Stakeholder(s).

Epics are written in the initial stages of the project, when most User Stories are high-level functionalities or product descriptions, and requirements are broadly defined. They are large, unrefined User Stories in the Prioritized Product Backlog. Once these Epics come up in the Prioritized Product Backlog for completion in an upcoming Sprint, they are then broken down into smaller, more granular User Stories. These smaller User Stories are generally simple, short, and easy to implement functionalities or blocks of tasks to be completed in a Sprint.

Identified Risks

When creating Epics, new risks may be identified and such Identified Risks form an important output of this stage. These risks contribute to the development of the Prioritized Product Backlog (which could also be referred to as the Risk Adjusted Product Backlog). The Scrum Team members should attempt to identify all risks that could potentially impact the project. Only by looking at the project from different perspectives, using a variety of techniques, can they do this job thoroughly. Risk Identification is done throughout the project and Identified Risks become inputs to several Scrum processes including Create Prioritized Product Backlog, Groom Prioritized Product Backlog, and Demonstrate and Validate Sprint.

To know more, please visit: www.SCRUMstudy.com 

Agile vs Waterfall?

Agile and Waterfall are two different methods used in managing a project. Both the methods have their own pros and cons and choosing one model is based on many project-centric factors.

• Waterfall Method

The Waterfall model is a progressive design process which in the software development industry goes through stages such as Conception, Initiation, Analysis, Design, Construction, Testing, Implementation, and Maintenance and steadily moves downwards similar to a waterfall flowing down. After one stage is completed it moves to another and every stage has its own goals. This model is based on the standard workflow process which is followed in manufacturing and construction industries.

The benefit of using this model is that a project is divided into separate compartments which in turn decrease the dependency on individuals of a team. Any team member who leaves the project during the transition stages would not affect the execution of the project. This method also requires concrete documentation.

The cons of this method is that it is inflexible. In this method it is not possible to go back to a previous stage to alter the design in anyway. Hence it is very important to collect the requirements at the initial stage. This method is based on the logic that once we spend considerable amount of time in gathering the comprehensive requirements at the start of the project helps in saving time and effort later on.

• Agile Method
  On the other hand Agile method is incremental approach. The team works on small modules and then responds to user’s altered requirements rather than following a pre-determined plan. The design is simple and changes can be made as work progresses.

When compared to Waterfall method, here the testing and responding to user change requirements can happen during the same time in the course of the project. Here interactions among stakeholders is prioritized as compared to tools and processes.

This method became popular in 1990s after the many found the drawbacks of traditional Waterfall methods.

Conclusion

As you can see both the methods have their own advantages. Though Agile was developed to combat the disadvantages found in Waterfall method, Waterfall method still is considered in environments which is stable

Agile is considered to be a lightweight approach. The team focuses on smaller areas of work and hence overhead becomes less. The cost of the project also becomes less. Agile is more suitable when the user requirements are not clear and where the business environment is not stable. Also successful implementation of Agile requires skilled developers and also stakeholders who know what they exactly want.

 To know more, please visit: www.SCRUMstudy.com

All about Time-boxing in SCRUM

Scrum treats time as one of the most important constraints in managing a project. To address the constraint of time, Scrum introduces a concept called ‘Time-boxing’ which proposes fixing a certain amount of time for each process and activity in a Scrum project. This ensures that Scrum Team members do not take up too much or too little work for a particular period of time and do not expend their time and energy on work for which they have little clarity.

Some of the advantages of Time-boxing are as follows:

• Efficient development process
• Less overheads
• High velocity for teams

Time-boxing can be utilized in many Scrum processes, for example, in the Conduct Daily Standup process, the duration of the Daily Standup Meeting is Time-boxed. At times, Time-boxing may be used to avoid excessive improvement of an item (i.e., gold-plating).

Time-boxing is a critical practice in Scrum and should be applied with care. Arbitrary Time-boxing can lead to de-motivation of the team and may have the consequence of creating an apprehensive environment, so it should be used appropriately.

To know more, please visit www.SCRUMstudy.com

Various Dimensions of Team Specialization

In a large SCRUM project, Team Specialization may be required. There are three dimensions of Team Specialization.

The first dimension is the need for accomplishing specific tasks. For example, one Specialized Team might be an integration team that has specialized knowledge of continuous integration.. That knowledge could be especially important when and if there is a Release Readiness Sprint.

The second dimension is the need for special skills of single team members. Theoretically, all Scrum Team members are generalists and specialists in that they have knowledge of various fields and are experts in at least one. However, this might not be the case in a large project. Members of Specialized Teams may need to possess specific skills—such as special domain knowledge like security—which may not be available with all large project teams for which it is needed. For a large project, it would be extremely costly to train everybody in all domains. These experts with special skills and knowledge may work as temporary team members in different teams, and sometimes it may be necessary to hire them from external sources. Adding a new team member will impact the team velocity.

The third dimension is that there may be limitations in team flexibility. As mentioned above, in a large project it would be extremely costly to train everybody in all domains. That means that every team will have one or more domains they are good at, a few domains they can and will work on with some inputs and training, and other domains they cannot work on. When it comes to Sprint planning, every team will have a subset of User Stories that are naturally theirs, some that they can work on, and some they can’t work on because they don’t have the knowledge/skills.

The project will have to take the risk that they may not be able to get all the top-priority User Stories done in a Sprint due to these limitations and may need to develop some User Stores of lower priority while waiting for the availability of team members with specialized skills.

To know more, please visit: www.SCRUMstudy.com 

Who is a Product Owner?

Before we read about how to be an effective product owner, let us first understand who a product owner is and what he/she does.  A product owner is not a separate title but is a role that can be performed by a business analyst or even a representative of an end user.

A product owner is a stakeholder who acts as an interface between the business representatives and the project team. A product owner understands the business requirements and communicates it to the team for development on behalf of the customer. A product owner is responsible for creating Prioritized Product Backlog, attending daily standup meetings, and steering the development process successfully to meet the customer’s requirements. The product owner communicates the progress of the team to the sponsor and key stakeholders. He or she also continuously refines product requirements. It is also important that a product owner has  good business sense which is important while prioritizing user stories based on cost and functionality.

A product owner must be actively involved-

The test of an effective product owner is how well he/she balances the expectations of business representatives and capability of the team to deliver. There are several ways a product owner can be more effective. A common mistake product owners make is not committing enough time to understand the requirements of the Scrum Team. Product owners should be as hands-on as possible and schedule sufficient time to holding estimation workshops, planning sprints, and providing feedback for the team.

An empowered product owner nurtures an empowered team-

Customers most often expect more value to be delivered than what the team  is capable of delivering or might suggest several changes that can slowdown the speed of the development team. A product owner supports his team by managing customer’s expectations so that workflow is not affected due to unreasonable expectations. A product owner allows the team to estimate the effort required to complete the product backlog items identified for a particular sprint. At the same time, a product owner motivates the team to deliver the product backlog items committed fora sprint on time.

Technical knowledge is essential-

It is also important that product owners have some technical knowledge, though he/she does not necessarily have to be a developer themselves. Since, they will be interacting with the team on a regular basis, having a technical background can serve well while resolving issues. Technical knowledge can also help a product owner bridge the gap between technical and business aspects of a project while liaising with developers and business representatives.

To know more, please click on: www.SCRUMstudy.com 

Role of a Program Scrum Master

The Program Scrum Master is a facilitator who ensures that all project teams in the program are provided with an environment conducive to completing their projects successfully. The Program Scrum Master guides, facilitates, and teaches Scrum practices to everyone involved in the program; provides guidance to Scrum Masters of individual projects; clears impediments for the different project teams; coordinates with the Scrum Guidance Body to define objectives related to quality, government regulations, security, and other key organizational parameters; and, ensures that Scrum processes are being effectively followed throughout the program.

The Program Scrum Master interfaces with the Portfolio Scrum Master to ensure alignment of the program with the goals and objectives of the portfolio. He or she is also involved with appointing Scrum Masters for individual projects and ensuring that the vision, objectives, outcomes, and releases of individual projects in the program align with that of the program.

This role is similar to that of the Scrum Master except it meets the needs of the program or business unit rather than of a single Scrum Team.

For more informative articles on Scrum and Agile, please visit www.scrumstudy.com
Follow us on twitter – @SCRUMStudy_

Release Planning Sessions in SCRUM

Release Planning Sessions are conducted to develop a Release Plan. The plan defines when various sets of usable functionality or products will be delivered to the customer. In Scrum, the major objective of a Release Planning Meeting is to enable the Scrum Team to have an overview of the releases and delivery schedule for the product they are developing so that they can align with the expectations of the Product Owner and relevant stakeholders (primarily the project sponsor).

Many organizations have a strategy regarding release of products. Some organizations prefer continuous deployment, where there is a release after creation of specified usable functionality. Other organizations prefer phased deployment, where releases are made at predefined intervals. Depending on the organization’s strategy, Release Planning Sessions in projects may be driven by functionality, in which the objective is to deliver a release once a predetermined set of functionality has been developed; or the planning may be driven by date, in which the release happens on a predefined date.

Since Scrum framework promotes information based, iterative decision making over the detailed upfront planning practiced in traditional waterfall style project management, Release Planning Sessions need not produce a detailed Release Plan for the entire project. The Release Plan can be updated continually as relevant information is available.

To know more , please visit www.SCRUMstudy.com

Determining Size of a Scrum Team

It is important for the Scrum Team to possess all the essential skills required to carry out the work of the project. It is also necessary to have a high level of collaboration to maximize productivity, so that minimal coordination is required to get things done.

The optimum size for a Scrum Team is six to ten members—large enough to ensure adequate skill sets, but small enough to collaborate easily. A key benefit of a six to ten member team is that communication and management are typically simple and require minimal effort.

However, there may also be drawbacks. One major drawback is that smaller teams are more significantly impacted by the loss of a team member than larger teams, even for a short period of time. To address this problem, it may be possible for team members to have expert knowledge and skills outside their own specific role. However, this may be difficult and depends on the type of project, industry, and size of the organization. It is also recommended to have back-up persons to replace any person who may have to leave the Scrum Team.

In situations where the Scrum Team size exceeds ten people, multiple Scrum Teams can be formed to work on the project. Large or complex projects are often implemented as part of a program or portfolio. The Scrum framework can also be applied to manage even programs and portfolios. The logical approach of the guidelines and principles in this framework can be used to manage projects of any size, spanning geographies and organizations. Large projects may have multiple Scrum Teams working in parallel making it necessary to synchronize and facilitate the flow of information and enhance communication.

To know more, please visit www.SCRUMstudy.com