Scrum Processes & Phases

The Initiate phase is done at the beginning of a Scrum Project. In this phase, the Scrum Core team and Business stakeholders are identified, starting with the Product Owner, who creates a Project Vision, which serves as guidance for the whole project. Based on the Project Vision, an initial set of requirements is collected and documented in the form of Epics. These initial requirements are prioritized and used to create an initial Prioritized Product Backlog (the requirements document in a Scrum project).

As the final step in the Initiate Phase, a Release schedule is created.

It is not the goal of the Initiate phase to create a perfect plan for the whole project. There is no need for it, because change is expected and can easily be incorporated in a Scrum project due to the iterative nature of Scrum. Instead, the goal is to come up with a good initial plan for the project, ensuring that everything that will be done aligns with the business or high priority regulations, and to keep the initiate phase short in order to start value creation quickly.     

It is also important to realize that although all phases and processes are defined uniquely in the SBOK® Guide, they are not necessarily performed sequentially or separately. At times, it may be more appropriate to combine some phases and/or processes, depending on the specific needs of each project.

The following Processes are part of the Initiate phase of a Scrum Project.

• Create Project Vision— In this process, the Product Owner is identified. Based on the Project Business Case, the Product Owner then creates a Project Vision Statement. This Project Vision Statement provides the overall guidance, inspiration and focus for the project.
• Identify Scrum Master and Business Stakeholder(s)—In this process, the Scrum Master is identified using specific Selection Criteria that are focused on the soft skills and Scrum knowledge needed for this important role. Additionally, business stakeholders are identified.
• Form Scrum Team—In this process, Scrum Team members are identified based on skills required to accomplish the project deliverables as well as considerations for availability, costs and soft skills important for members of a Scrum Team. Normally the Product Owner has the primary responsibility of selecting team members, but often does so in collaboration with the Scrum Master.
• Develop Epic(s)—In this process, the Project Vision Statement serves as the basis for developing Epics, which define the high-level requirements for the project. The Product Owner may use User Group meetings and other tools to collect requirements from business stakeholders.
• Create Prioritized Product Backlog—In this process, Epics are refined, elaborated and, most importantly, prioritized according to their respective business value to create a Prioritized Product Backlog for the project. Additionally, based on the Scrum Guidance Body recommendations, the Product Owner and the Scrum Team establish the Done Criteria for the project.
• Conduct Release Planning—In this process, the Product Owner with support of the Scrum Team develops the initial Release Schedule, which is communicated to and shared with business stakeholders. It is understood that the iterative nature of Scrum may necessitate future adjustments to the Release Schedule. The Length of Sprints is also determined in this process.

After the Initiate Phase is completed, the iterative Sprint cycles can commence. Plan and Estimate is the first of three phases that are done repetitively, in every Sprint cycle.

At the beginning of a Sprint, the Product Owner and Scrum Team, facilitated by the Scrum Master, plan the Sprint. The Product Owner refines the highest priority Epics into a set of well written and estimated User Stories, which the Scrum Team commits to completing in the upcoming Sprint based on team velocity assumptions. The Scrum Master also creates the Sprint Backlog with the list of User Stories committed to be done as part of the Sprint

The Scrum Team then plans its work in more detail by identifying and optionally estimating the tasks it must complete in order to deliver the User Stories for the Sprint. As a final planning step for the Sprint, the team updates the Sprint Backlog with details of tasks and if available, their estimates. The Updated Sprint Backlog will be used in the Implement phase to track the teams progress during the Sprint.

It is also important to realize that although all phases and processes are defined uniquely in the SBOK® Guide, they are not necessarily performed sequentially or separately. At times, it may be more appropriate to combine some phases and/or processes, depending on the specific needs of each project.

The following processes are covered during the Plan & Estimate phase.

• Create User Stories—In this process, User Stories and their related User Story Acceptance Criteria are created. User Stories are usually written by the Product Owner and elaborated from Epics defined in the Initiate process. User Stories are designed to ensure that the customer’s requirements are clearly depicted and can be fully understood by all business stakeholders. These User Stories need to be tangible enough and satisfy the Definition of Ready so that they can be used for estimation by the Scrum Team. User Story Workshops may be held which involves Scrum Team members understanding the User Stories created by the Product Owner. User Stories are incorporated into the Prioritized Product Backlog.
• Estimate User Stories—In this process, the Scrum Team, supported by the Scrum Master, estimates User Stories, and identifies the effort required to develop the functionality described in each User Story. Only User Stories which satisfy the Definition of Ready and are properly defined by the Product Owner are estimated by the Scrum Team. Although the Product Owner does not play an active role in the estimation itself, he / she may be consulted to clarify any questions the Scrum Team might have related to the User Stories to be estimated.      
• Commit User Stories—In this process, the Scrum Team commits to delivering a set of User Stories for the Sprint, with the input and approval from the Product Owner. Which User Stories the Scrum Team is asked by the Product Owner to commit to depends on the value-based priority of each User Story. How many User Stories the Scrum Team   commits to, depends on the estimated effort and how much the team can complete, based on the team’s velocity, in one Sprint. The process results in creation of the Sprint Backlog, which is a subset of the Prioritized Product Backlog, and contains the Committed User Stories which are assigned to a particular Sprint. This is refined further with task level details as Sprint Planning continues. With this commitment of the Scrum Team, given at the beginning of a Sprint as part of the Sprint Planning, the content of the Sprint is defined and cannot be changed once the Sprint implementation phase has begun.
• Identify Tasks—In this process, the Committed User Stories are broken down into specific tasks and compiled into a Task List, through a tool called Decomposition. This Decomposition could either be done in the beginning of the Sprint for all User Stories, or can be done for individual User Stories before the  team starts working on the tasks required for the User Story.The Product Owner does not play an active role in the creation of the task list, but he / she needs to be available to answer any questions from the Scrum Team that may arise while it breaks down the User Stories. 
• Estimate Tasks—This is an optional process. In this process, if the Scrum Team sees value in doing so, the Scrum Team estimates the effort required to accomplish each task in the task list. The estimation is done using the same tools that are used for the Estimate User Stories process. Task Estimates could either be done at the beginning of the Sprint for all Tasks, or can be done for individual Tasks just before the team starts working on the particular User Story/Task. The result of this process is an Effort Estimated Task List.
• Update Sprint Backlog—In this process, the Scrum Core Team updates the Sprint Backlog with details of the tasks, and if available the task estimates. The Updated Sprint Backlog will be used in the Implement phase to track the teams progress during the Sprint.

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 busines stakeholders and better estimations by the team. Some User Stories may be too large to handle within a single Sprint. These large User Stories are often called Epics. Once Epics come up in the Prioritized Product Backlog to be completed in an upcoming Sprint, they are further decomposed into smaller User Stories.

The Prioritized Product Backlog is a dynamic list that is continuously updated because of reprioritization and new, updated, refined, and sometimes, deleted User Stories. These updates to the backlog are typically the result of changing business requirements.

Please find an example of a User Story format.

Every User Story has an associated Acceptance Criteria. User Stories are subjective, so the Acceptance Criteria provide the objectivity required for the User Story to be considered as Done or not Done during the Sprint Review. Acceptance Criteria provide clarity to the team on what is expected of a User Story, remove ambiguity from requirements, and help in aligning expectations. The Product Owner defines and communicates the Acceptance Criteria to the Scrum Team. In the Sprint Review Meetings, the Acceptance Criteria provide the context for the Product Owner to decide if a User Story has been completed satisfactorily. It is important and the responsibility of the Scrum Master to ensure that the Product Owner does not change the Acceptance Criteria of a committed User Story in the middle of a Sprint.

When developing User Story Acceptance Criteria, the following should be considered:

• Acceptance Criteria should not be vague, ambiguous, or too generalized.
• Defined Acceptance Criteria should ensure that the team is able to verify that the outcomes are in alignment with the sponsor organization’s goals and objectives.

The Scrum Team, supported by the Scrum Master, estimates User Stories, and identifies the effort required to develop the functionality described in each User Story. Only User Stories which satisfy the Definition of Ready and are properly defined by the Product Owner are estimated by the Scrum Team. Although the Product Owner does not play an active role in the estimation itself, he / she may be consulted to clarify any questions the Scrum Team might have related to the User Stories to be estimated.

During Sprint Planning Meetings, the User Stories are taken up for discussion by the Scrum Core Team. If not already done during the Creation or the Refining of the Product Backlog, each User Story is evaluated and assigned a high-level estimate based on relative story points.

As new or updated User Stories are refined in the Backlog, the Scrum Team will assign or update the high-level estimates for each User Story. Relative sizing, or story points, can be used for estimating the overall size of a User Story or feature. This approach assigns a story point value based on an overall assessment of the size of a User Story with consideration given to risk, amount of effort required, and level of complexity. This assessment will be conducted by the Scrum Team and a story point value will be assigned. Once an evaluation is done on one User Story in the Prioritized Product Backlog, the Scrum Team can then evaluate other User Stories relative to that first story. It should be noted that story point calibration for each team would be different, and the number of user story points completed cannot be used for comparison across teams. Also, the Estimation Method selected would depend on the level of estimation detail required by the team. 

Numerous estimation methods can be used as tools to estimate User Stories. Some important tools are:

• Planning Poker: Planning Poker, also called Estimation Poker, is a derivative of the Wideband Delphi technique. This is an estimation technique which uses consensus to estimate relative sizes of User Stories or the effort required to create them. In Planning Poker, each team member is assigned a deck of cards. Each card is numbered in a sequence and the numbers represent complexity of the problem, in terms of time or effort, as estimated by the team member. The Scrum Team members assess the item (User Story or Task) to understand it better before providing their estimate for developing it. Then, each member picks a card from the deck that represents their estimate for the item. If the majority or all team members select the same card then the estimate indicated by that card will be the estimate for that item. If there is no consensus, then the team members discuss reasons for selecting different cards or estimates. After this discussion they pick cards again. This sequence continues until all the assumptions are understood, misunderstandings are resolved, and consensus or agreement is reached. Planning Poker advocates greater interaction and enhanced communication among the participants. It facilitates independent thinking by participants, thus avoiding the phenomenon of group think.
• Fist of Five: Fist of Five is a simple and fast mechanism that can be used as an estimation practice, as well as a general group consensus building technique. After initial discussion on a given item for estimation, the Scrum Team members are each asked to vote on a scale of 1 to 5 using their fingers. Used as an estimation tool, the number of fingers displayed indicate the relative estimate value. Team members with outlier estimates (highest and lowest values) explain their rational for their estimates to the group and are discussed. Once the team has discussed, another Fist of Five round is conducted or a collective decision is made. The value in using this technique is not only consensus building but also driving discussion because team members are asked to explain the reason for their estimates. They are also given the opportunity to express any issues or concerns. Used as a general consensus building technique, the proposal or pending decision under consideration is initially discussed, then the team members vote based on their level of agreement and desire for discussion:
  • One finger: I disagree with the group's conclusion and have major concerns.
  • Two fingers: I disagree with the group's conclusion and would like to discuss some minor issues.
  • Three fingers: I am not sure and would like to go with the group's consensus conclusion.
  • Four fingers: I agree with the group's conclusion and would like to discuss some minor issues.

Five fingers: I wholeheartedly agree with the group's conclusion.

In Sprint Planning Meetings, the Scrum Team gets together to plan the work to be done in the Sprint. The team reviews the Estimated User Stories at the top of the Prioritized Product Backlog. The Product Owner is present during this meeting in case clarification of User Stories or priorities are required. To help ensure that the group stays on topic, this meeting should be Time-boxed, with the standard length limited to two hours per week of Sprint duration. This assists in preventing the tendency to stray into discussions that should occur in other meetings, like the Release Planning or Sprint Review Meetings. As part of this meeting the entire Scrum Team will commit to delivering a subset of User Stories from the Prioritized Product Backlog in the Sprint. In Sprint Planning Meetings, the Scrum Team convenes to plan the work to be done in the Sprint. The team reviews each Committed User Story for the Sprint and identifies actionable activities, or tasks required to implement the deliverables necessary to fulfill the User Story and meet acceptance criteria.

The list of the User Stories to be executed by the Scrum Team in the upcoming Sprint is called the Sprint Backlog. This is a subset of the Prioritized Product Backlog and contains the Committed User Stories which are assigned to a particular Sprint. This is refined further with task level details as Sprint Planning continues.

It is common practice that the Sprint Backlog is represented on a Scrumboard or task board, which provides a constantly visible depiction of the status of the User Stories in the backlog.

Once the Sprint Backlog is finalized and committed to by the Scrum Team, new User Stories should not be added. If new requirements arise during a Sprint, they will be added to the overall Prioritized Product Backlog and included in a future Sprint.

After the User Stories are estimated, the Scrum Team commits to delivering a set of User Stories for the Sprint, with the input and approval from the Product Owner. Which User Stories the Scrum Team is asked by the Product Owner to commit to depends on the value-based priority of each User Story. How many User Stories the Scrum Team   commits to, depends on the estimated effort and how much the team can complete, based on the team’s velocity, in one Sprint.

The process results in creation of the Sprint Backlog, which is a subset of the Prioritized Product Backlog, and contains the Committed User Stories which are assigned to a particular Sprint. This is refined further with task level details as Sprint Planning continues.

With this commitment of the Scrum Team, given at the beginning of a Sprint as part of the Sprint Planning, the content of the Sprint is defined and cannot be changed once the Sprint implementation phase has begun.

Sprint Velocity is the rate at which the team can complete the work in a Sprint. It is usually expressed in the same units as those used for estimation, normally story points or ideal time. A record of the Sprint Velocity of the team for each Sprint is maintained and used as a reference in future Sprints. The Previous Sprint Velocity becomes the most important factor in determining the amount of work the team can commit to in a subsequent Sprint. Any changes in the situation or conditions since the last Sprint are accounted for to ensure better estimation of Sprint velocity for the upcoming Sprint.

It is important to track the progress of a Sprint and to know where the Scrum Team stands in terms of completing the tasks in the Sprint Backlog. A variety of tools can be used to track the work in a Sprint, but one of the most common is a Scrumboard, also known as a task board or a progress chart. Scrum's transparency comes from openly viewable information tools like the Scrumboard, which shows the progress of the team. The team uses a Scrumboard to plan and track progress during each Sprint.

The most basic version of a Scrumboard is divided into three sections: To Do (sometimes referred to as Work Not Started), Work In Progress(sometimes referred to as “In Progress”), and Completed Work(sometimes referred to as “Complete”. Sticky notes representing each task or User Story are placed in the appropriate category to reflect the status of the work. They are moved forward to the next category as the work progresses.

A typical Scrumboard is shown in figure below. It shows all the User Stories in the left column and has three columns named as “To Do”, “In Progress” and “Complete.” As Tasks are identified and worked on in later processes, those would be depicted under their respective columns.

                                                      Typical Scrumboard

A variation of the Scrumboard contains four sections to indicate the progress of the estimated tasks for the Sprint: for example, a ‘To Do’ column for tasks not yet started, an ‘In Progress’ column for the tasks started but not yet completed, a ‘Testing’ column for tasks completed but in the process of being tested, and a ‘Complete’ column for the tasks that have been completed and successfully tested. Note that instead of ‘Testing’ column, the team may have any other section created in the Scrumboard which properly depicts the progression of work done by the team. A sample Scrumboard with four columns is shown in figure below.

                                              Scrumboard with four sections

The Scrumboard should preferably be maintained manually on paper or a white board, but can also be maintained electronically in a spreadsheet or through a Scrum Project Tool.

The Scrum Team should change or add to the Scrumboard as required so that the Scrumboard provides visual information and control about the work going on as agreed and committed by the team.

Task list is a comprehensive list that contains all the tasks to which the Scrum Team has committed for the current Sprint. It contains descriptions of each task derived during the Identify Tasks process. The Task List must include any testing and integration efforts so that the Product Increment from the Sprint can be successfully integrated into the deliverables from previous Sprints.

As tasks are identified, the Scrumboard as described in section 9.3.3.3 is updated to show the tasks associated with the User Stories. Tasks are typically shown through sticky notes in a physical Scrumboard, or entries under the User Stories for an electronic Scrum Project Tool. For example, the Scrumboard below shows that three User Stories 1, 2 and 3 have been decomposed into tasks, but User Story 4 has not yet been decomposed into tasks.

At the beginning of a Sprint, all tasks for that Sprint are placed in the ‘To Do’ column and are subsequently moved forward according to their progress. For example, User Story 1 has 6 tasks, all of which are categorized as “To Do,” which indicates that the Scrum Team has not started working on the tasks.

                                Scrumboard with identified Tasks

As the team keeps adding/updating tasks, and assigning tasks to work on, the Scrumboard keeps getting updated with the additional tasks, and status of the tasks. Also, if the team estimates the tasks, the task estimates are also added to the Scrumboard.

Implement is the second of the three phases that are done repetitively in every Sprint. This phase starts right after the Sprint planning. It is the core of every Scrum project where the bulk of the work is done.

The Scrum Team, facilitated by the Scrum Master, creates the deliverables that are associated with the committed user Stories by working on and completing the tasks it has identified in the previous phase.

While the Scrum Team is creating the deliverables of the Sprint, the Product Owner refines the Prioritized backlog to keep it up to date with any change in requirements and / or priorities and to ensure that the set of User Stories the Product Owner would like the team to commit to in the next Sprint will be ready for commitment.

It is also important to realize that although all phases and processes are defined uniquely in the SBOK® Guide, they are not necessarily performed sequentially or separately. At times, it may be more appropriate to combine some phases and/or processes, depending on the specific needs of each project.

The following processes are covered in the Implement phase.

• Create Deliverables— In this process, the Scrum team creates the Sprint Deliverables by working on the tasks in the Sprint Backlog. The team is supported by the Scrum Master, who facilitates meetings for the team, addresses impediments the team faces, and does whatever he / she can do to allow the Scrum Team members to focus on the creation of the Sprint Deliverables. The Scrum Team uses a Scrumboard to track its progress during the Sprint. The Scrum Team uses the information about its progress to get a good indication of its ability to deliver according to its commitment and, if necessary, to take action to secure the most valuable outcome of the Sprint that is possible under the given circumstances. This is the process where the Scrum Team and the Scrum Master spend most of their time.
• Conduct Daily Standup— In this process, a highly focused Daily Standup Meeting is conducted. This time-boxed meeting is the forum for the Scrum Team to update each other on their progress and any impediments they may be facing by each answering three specific questions.

Refine Prioritized Product Backlog— In this process, the Product Owner continuously updates and maintains the Prioritized Product Backlog. A Prioritized Product Backlog Review Meeting may be held, in which any changes or updates to the backlog are discussed and incorporated into the Prioritized Product Backlog as appropriate. In order to keep the Prioritized backlog up to date with any change in requirements and / or priorities, the Product Owner continually works with the Customer and other business stakeholders to capture and understand any changes in their needs. In order to ensure that the set of User Stories the Product Owner would like the team to commit to in the next Sprint will be ready for commitment, the Product Owner refines existing Epics and User Stories in the Prioritized Product Backlog, and ensures that the User Stories satisfy the Definition of Ready. As part of the refining of the Prioritized Product Backlog, the Product Owner also works with the Scrum Team to get feedback and questions related to the updates in the Prioritized Product Backlog, potentially including estimates. If changes in requirements and / or the overall progress of the Scrum Team require changes to the Release Schedule and / or the business justification, the Product Owner will also make these changes in this process. This is the process where the Product Owner will spend most of his / her time.

The Review and Retrospect phase is concerned with reviewing the deliverables and the work that has been done and determining ways to improve the practices and methods used to do project work. In large organizations the Review and Retrospect processes may also include convening Scrum of Scrums Meetings. This phase and its processes cover the perspective of one Scrum Team working on one Sprint to produce potentially shippable Deliverables, which could be part of a larger project, program, or portfolio.

The following processes are part of the Review and Retrospect phase.

• Demonstrate and Validate Sprint—In this process, the Scrum Team demonstrates the Sprint Deliverables to the Product Owner and relevant business stakeholders in a Sprint Review Meeting. The purpose of this meeting is to secure approval and acceptance of the product or service by the Product Owner.
• Retrospect Sprint—In this process, the Scrum Master and Scrum Team meet to discuss the lessons learned throughout the Sprint. This information is documented as lessons learned which can be applied to future Sprints. Often, because of this discussion, there may be Agreed Actionable Improvements or Updated Scrum Guidance Body Recommendations.

The Scrum Core Team members and relevant Business stakeholder(s) participate in Sprint Review Meetings to accept the deliverables which meet the User Story Acceptance Criteria and reject unacceptable deliverables. These meetings are convened at the end of every Sprint. The Scrum Team demonstrates the achievements from the Sprint, including the new functionalities or products created. This provides an opportunity for the Product Owner and Business stakeholder(s) to inspect what has been completed so far and to determine if any changes should be made in the project or processes in subsequent Sprints. The Sprint Review Meeting is time-boxed to four hours for a one-month Sprint and can be scaled according to the length of the Sprint. During the Sprint Review Meeting, the Scrum Team presents the deliverables of the current Sprint to the Product Owner, who may accept or reject the deliverables.

The Retrospect Sprint Meeting is an important element of the ‘inspect-adapt’ Scrum framework and it is the final step in a Sprint. All Scrum Team members attend the meeting, which is facilitated or moderated by the Scrum Master. It is recommended, but not required for the Product Owner to attend. One team member acts as the scribe and documents discussions and items for future action. It is essential to hold this meeting in an open and relaxed environment to encourage full participation by all team members. Discussions in the Retrospect Sprint Meeting encompass both what went wrong and what went right. Primary objectives of the meeting are to identify three specific items:

• Things the team needs to keep doing: best practices
• Things the team needs to begin doing: process improvements
• Things the team needs to stop doing: process problems and bottlenecks

These areas are discussed, and a list of Agreed Actionable Improvements is created.

The Release phase emphasizes delivering the Accepted Deliverables to the customer and identifying, documenting, and internalizing the lessons learned during the project. The Release phase contains the following processes.

• Ship Deliverables—In this process, Accepted Deliverables are delivered or transitioned to the relevant business stakeholders. A formal Working Deliverables Agreement documents the successful completion of the Sprint.
• Retrospect Release—In this process, which completes a Release, business stakeholders and Scrum Core Team members assemble to reflect on the Release and identify, document and internalize the lessons learned. Often these lessons lead to the documentation of Agreed Actionable Improvements, to be implemented in future Releases in the project.

The Retrospect Release Meeting is a meeting to determine ways in which team collaboration and effectiveness can be improved in future projects. Positives, negatives, and potential opportunities for improvement are also discussed. This meeting is not Time-boxed and may be conducted in person or in a virtual format. Attendees include the Project Team, Chief Scrum Master, Chief Product Owner, and Business Stakeholder(s). During the meeting, lessons learned are documented and participants look for opportunities to improve processes and address inefficiencies.