/
Scrum Phases and Processes (Project Lifecycle)

Scrum Phases and Processes (Project Lifecycle)

Owned by Ammar Ahmed Butt (Deactivated)
May 22, 2022

Scrum vs. Traditional Project Management

Scrum and most of the traditional project management methods define risk as ‘uncertain event(s) that could positively or negatively affect the achievement of project objectives.’ Also, risks are identified, assessed, planned for, and communicated continually. In Traditional project management models, there is an emphasis on detailed upfront planning to identify, assess, and determine risk responses for all project risks. During project execution, any project team member can identify risks and the project manager or the project management office or project support staff can update them in the Risk Log or Risk Register. The project manager regularly monitors and controls all risks and usually identifies specific individuals in the team to take responsibility for different aspects of risks. In Scrum, any Scrum Team member can identify risks and the Product Owner can update the identified risks in the Risk-Adjusted Prioritized Product Backlog. The Scrum principles of Empirical Process Control and Iterative Development enable the Scrum Team to constantly keep identifying risks and adding them to the Prioritized Product Backlog, where such risks are prioritized with other existing User Stories in the backlog, to be mitigated in subsequent Sprints. The Scrum Team has collective responsibilities for managing all risks for the Sprint.

1. INITIATE

This chapter includes the processes related to the initiation of a project: Create Project Vision, Identify Scrum Master and Stakeholder(s), Form Scrum Team, Develop Epic(s), Create Prioritized Product Backlog, and Conduct Release Planning.

Initiate, as defined

• Portfolios, programs, and/or projects in any industry
• Products, services, or any other results to be delivered to stakeholders
• Projects of any size or complexity The term “product” in the SBOK™ Guide may refer to a product, service, or other deliverables.

Scrum can be applied effectively to any project in any industry—from small projects or teams with as few as six team members to large, complex projects with up to several hundred team members. To facilitate the best application of the Scrum framework, this chapter identifies inputs, tools, and outputs for each process as either “mandatory” or “optional.” Inputs, tools, and outputs denoted by asterisks (*) are mandatory, or considered critical to success, whereas those with no asterisks are optional. It is recommended that the Scrum Team and those individuals being introduced to the Scrum framework and processes focus primarily on the mandatory inputs, tools, and outputs; while Product Owners, Scrum Masters, and other more experienced Scrum practitioners strive to attain a more thorough knowledge of the information in this entire chapter. It is also important to realize that although all 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 processes, depending on the specific requirements of each project.

Initiate Phase—Data Flow Diagram

 

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

The mandatory inputs, tools, and outputs for processes in the Initiate phase.

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

a) Create Project Vision

—In this process, the Project Business Case is reviewed to create a Project Vision Statement that will serve as the inspiration and provide the focus for the entire project. The Product Owner is identified in this process.

Create Project Vision—Inputs, Tools, and Outputs

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

Create Project Vision—Data Flow Diagram

b) Identify Scrum Master and Stakeholder(s)

—In this process, the Scrum Master and Stakeholders are identified using specific Selection Criteria.

Identify Scrum Master and Stakeholder(s)—Inputs, Tools, and Outputs

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

Identify Scrum Master and Stakeholder(s)—Data Flow Diagram

c) Form Scrum Team

—In this process, Scrum Team members are identified. Normally the Product Owner has the primary responsibility of selecting team members but often does so in collaboration with the Scrum Master.

Form Scrum Team—Inputs, Tools, and Outputs

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

Form Scrum Team—Data Flow Diagram

d) Develop Epic(s)

—In this process, the Project Vision Statement serves as the basis for developing Epics. User Group Meetings may be held to discuss appropriate Epics.

Develop Epic(s)—Inputs, Tools, and Outputs
Develop Epic(s)—Data Flow Diagram

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

e) Create Prioritized Product Backlog

—In this process, Epic(s) are refined, elaborated, and then prioritized to create a Prioritized Product Backlog for the project.

Done Criteria

The Done criteria is also established at this point.

Create Prioritized Product Backlog—Inputs, Tools, and Outputs
Create Prioritized Product Backlog—Data Flow Diagram

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

f) Conduct Release Planning

—In this process, the Scrum Core Team reviews the User Stories in the Prioritized Product Backlog to develop a Release Planning Schedule, which is essentially a phased deployment schedule that can be shared with the project stakeholders. The Length of Sprints is also determined in this process.

Conduct Release Planning—Inputs, Tools, and Outputs

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

2. PLAN AND ESTIMATE

The Plan and Estimate phase consists of processes related to planning and estimating tasks, which include Create User Stories, Estimate User Stories, Commit User Stories, Identify Tasks, Estimate Tasks, and Create Sprint Backlog.

Plan and Estimate, as defined in A Guide to the Scrum Body of Knowledge (SBOK™ Guide), is applicable to the following:

• Portfolios, programs, and/or projects in any industry
• Products, services, or any other results to be delivered to stakeholders
• Projects of any size or complexity

The term “product” in the SBOK™ Guide may refer to a product, service, or other deliverables. Scrum can be applied effectively to any project in any industry—from small projects or teams with as few as six team members to large, complex projects with up to several hundred team members.

To facilitate the best application of the Scrum framework, this chapter identifies inputs, tools, and outputs for each process as either “mandatory” or “optional.” Inputs, tools, and outputs denoted by asterisks (*) are mandatory, or considered critical to success, whereas those with no asterisks are optional.

It is recommended that the Scrum Team and those individuals being introduced to the Scrum framework and processes focus primarily on the mandatory inputs, tools, and outputs; while Product Owners, Scrum Masters, and other more experienced Scrum practitioners strive to attain a more thorough knowledge of the information in this entire chapter. It is also important to realize that although all 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 processes, depending on the specific requirements of each project.

Plan and Estimate Overview
Plan and Estimate Overview (Essentials)

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

a) 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 are designed to ensure that the customer’s requirements are clearly depicted and can be fully understood by all stakeholders. User Story Writing Workshops may be held which involves Scrum Team members creating the User Stories. User Stories are incorporated into the Prioritized Product Backlog.

User Story Format:

As a, I should be able to, so that.

User Story Example: As a Database Administrator, I should be able to revert a selected number of database updates so that the desired version of the database is restored.

Create User Stories—Inputs, Tools, and Outputs
Create User Stories—Data Flow Diagram

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

b) Estimate User Stories

—In this process, the Product Owner clarifies User Stories in order for the Scrum Master and Scrum Team to estimate the effort required to develop the functionality described in each User Story.

Estimate User Stories—Inputs, Tools, and Outputs
Estimate User Stories—Data Flow Diagram

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

– Estimation Methods

https://shopdev.atlassian.net/l/c/2hMu4x1j - Check Estimation Methods here.

c) Commit User Stories

— In this process, the Scrum Team commits to deliver User Stories approved by the Product Owner for a Sprint. The result of this process would be Committed User Stories

Commit User Stories—Data Flow Diagram

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

d) Identify Tasks

—In this process, the Committed User Stories are broken down into specific tasks and compiled into a Task List.

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

e) Estimate Tasks

—In this process, the Scrum Core Team estimates the effort required to accomplish each task in the Task List. The result of this process is an Effort Estimated Task List.

– Estimation Methods

https://shopdev.atlassian.net/l/c/2hMu4x1j - Check Estimation Methods here.

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

f) Create Sprint Backlog

—In this process, the Scrum Core Team holds Sprint Planning Meetings where the group creates a Sprint Backlog containing all tasks to be completed in the Sprint.

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

 

3. IMPLEMENT

The Implement phase is related to the execution of the tasks and activities to create a project’s product. These activities include creating various deliverables, conducting Daily Standup Meetings, and grooming (i.e., reviewing, fine-tuning, and regularly updating) the Product Backlog at regular intervals.

Implement, as defined in A Guide to the Scrum Body of Knowledge (SBOK™ Guide), is applicable to the following:

• Portfolios, programs, and/or projects in any industry
• Products, services, or any other results to be delivered to stakeholders
• Projects of any size or complexity

The term “product” in the SBOK™ Guide may refer to a product, service, or other deliverables. Scrum can be applied effectively to any project in any industry—from small projects or teams with as few as six team members to large, complex projects with up to several hundred team members.

To facilitate the best application of the Scrum framework, this chapter identifies inputs, tools, and outputs for each process as either “mandatory” or “optional.” Inputs, tools, and outputs denoted by asterisks (*) are mandatory, or considered critical to success, whereas those with no asterisks are optional.

It is recommended that the Scrum Team and those individuals being introduced to the Scrum framework and processes focus primarily on the mandatory inputs, tools, and outputs; while Product Owners, Scrum Masters, and other more experienced Scrum practitioners strive to attain a more thorough knowledge of the information in this entire chapter. It is also important to realize that although all 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 processes, depending on the specific requirements of each project.

Implement Overview
Implement Overview (Essentials)

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

 

a) Create Deliverables

—In this process, the Scrum Team works on the tasks in the Sprint Backlog to create Sprint Deliverables. A Scrum board is often used to track the work and activities being carried out. Issues or problems being faced by the Scrum Team could be updated in an Impediment Log.

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

Impediment Log

An impediment is any hindrance or hurdle that reduces the productivity of the Scrum Team. Impediments must be identified, resolved, and removed if the team is to continue working effectively. Impediments can be internal to the team, such as inefficient workflow or lack of communication, or they can be external. Examples of external impediments might include software license issues or unnecessary documentation requirements. The Scrum framework, with its inherent transparency, facilitates the swift and easy identification of impediments. Failure to identify or deal with impediments can be very costly. Impediments should be formally recorded by the Scrum Master in an Impediment Log and can be discussed during Daily Standup Meetings and Sprint Review Meetings as appropriate.

b) Conduct Daily Standup

—In this process, every day a highly focused, Time-boxed meeting is conducted referred to as the Daily Standup Meeting. This is the forum for the Scrum Team to update each other on their progress and any impediments they may be facing.

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

c) Groom Prioritized Product Backlog

—In this process, the Prioritized Product Backlog is continuously updated and maintained. 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.

 

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

Rejected Deliverables

In cases where a deliverable does not meet the Acceptance Criteria, it is considered a Rejected Deliverable. The Rejected Deliverables are normally not kept in a separate list. They simply remain in the Prioritized Product Backlog and don't get marked as done so that they can be reprioritized in the Groom Prioritized Product Backlog process and be considered for development in the next Sprint.

 

4. REVIEW AND RETROSPECT

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.

 

Review and Retrospect, as defined in A Guide to the Scrum Body of Knowledge (SBOK™ Guide), is applicable to the following:

• Portfolios, programs, and/or projects in any industry
• Products, services, or any other results to be delivered to stakeholders
• Projects of any size or complexity

The term “product” in the SBOK™ Guide may refer to a product, service, or other deliverables. Scrum can be applied effectively to any project in any industry—from small projects or teams with as few as six team members to large, complex projects with up to several hundred team members.

To facilitate the best application of the Scrum framework, this chapter identifies inputs, tools, and outputs for each process as either “mandatory” or “optional.” Inputs, tools, and outputs denoted by asterisks (*) are mandatory, or considered critical to success, whereas those with no asterisks are optional.

It is recommended that the Scrum Team and those individuals being introduced to the Scrum framework and processes focus primarily on the mandatory inputs, tools, and outputs; while Product Owners, Scrum Masters, and other more experienced Scrum practitioners strive to attain a more thorough knowledge of the information in this entire chapter. It is also important to realize that although all 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 processes, depending on the specific requirements of each project.

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

a) Demonstrate and Validate Sprint

—In this process, the Scrum Team demonstrates the Sprint Deliverables to the Product Owner and relevant 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.

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

b) 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, as a result of this discussion, there may be Agreed Actionable Improvements or Updated Scrum Guidance Body Recommendations.

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

5. RELEASE

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

Release, as defined in A Guide to the Scrum Body of Knowledge (SBOK™ Guide), is applicable to the following:

• Portfolios, programs, and/or projects in any industry
• Products, services, or any other results to be delivered to stakeholders
• Projects of any size or complexity

The term “product” in the SBOK™ Guide may refer to a product, service, or other deliverables. Scrum can be applied effectively to any project in any industry—from small projects or teams with as few as six team members to large, complex projects with up to several hundred team members.

To facilitate the best application of the Scrum framework, this chapter identifies inputs, tools, and outputs for each process as either “mandatory” or “optional.” Inputs, tools, and outputs denoted by asterisks (*) are mandatory, or considered critical to success, whereas those with no asterisks are optional.

It is recommended that the Scrum Team and those individuals being introduced to the Scrum framework and processes focus primarily on the mandatory inputs, tools, and outputs; while Product Owners, Scrum Masters, and other more experienced Scrum practitioners strive to attain a more thorough knowledge of the information in this entire chapter. It is also important to realize that although all 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 processes, depending on the specific requirements of each project.

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

 

a) Ship Deliverables

—In this process, Accepted Deliverables are delivered or transitioned to the relevant stakeholders. A formal Working Deliverables Agreement documents the successful completion of the Sprint.

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

b) Retrospect Project

—In this process, which completes the project, organizational stakeholders and Scrum Core Team members assemble to retrospect the project and identify, document, and internalize the lessons learned. Often, these lessons lead to the documentation of Agreed Actionable Improvements, to be implemented in future projects.

Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.

Retrospect Project Meeting

The Retrospect Project 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 Stakeholder(s). During the meeting, lessons learned are documented and participants look for opportunities to improve processes and address inefficiencies.

Scrum Process Core Roles and Responsibilities

Processes 

Product Owner Responsibilities

Create Project Vision 

  • Defines the Project Vision • Helps create the Project Charter and Project Budget

Identify Scrum Master and Stakeholder(s)

  • Helps finalize Scrum Master for the project • Identifies Stakeholder(s)

Form Scrum Team 

  • Helps determine Scrum Team members • Helps develop a Collaboration Plan • Helps develop the Team Building Plan with Scrum Master(s)

 Develop Epic(s)

  • Creates Epic(s) and Personas 

 Create Prioritized Product Backlog

  • Prioritizes Prioritized Product Backlog Items • Defines Done Criteria

 Conduct Release Planning

  • Creates Release Planning Schedule • Helps determine Length of Sprint

Create User Stories 

  • Helps create User Stories • Defines Acceptance Criteria for every User Story

Estimate User Stories

  • Clarifies User Stories

Commit User Stories 

  • Works with Scrum Team to commit User Stories

Identify Tasks 

  • Explains User Stories to the Scrum Team while creating the Task List

Estimate Tasks 

  • Provides guidance and clarification to the Scrum Team in estimating effort for tasks

Create Sprint Backlog 

  • Clarifies requirements to the Scrum Team while creating the Sprint Backlog

Create Deliverables 

  • Clarifies business requirements to the Scrum Team

Groom Prioritized Product Backlog 

  • Grooms the Prioritized Product Backlog 

Demonstrate and Validate Sprints

  • Accepts/Rejects Deliverables • Provides necessary feedback to Scrum Master and Scrum Teams • Updates Release Plan and Prioritized Product Backlog 

Ship Deliverables 

  • Helps deploy Product Releases and coordinates this with the customer 

Retrospect Project/Sprint

  • Participates in Retrospective Project/Sprint Meetings

Processes 

Scrum Master Responsibilities

Identify Scrum Master and Stakeholder(s) 

  • Helps identify Stakeholder(s) for the project

Form Scrum Team

  • Facilitates selection of the Scrum Team • Facilitates creation of the Collaboration Plan and the Team Building  Plan • Ensures backup resources are available for smooth project functioning

Develop Epic(s)

  • Facilitates creation of Epic(s) and Personas

Create Prioritized Product Backlog 

  • Helps Product Owner in the creation of the Prioritized Product Backlog and the definition of the Done Criteria

Conduct Release Planning 

  • Coordinates creation of Release Planning Schedule • Determines Length of Sprint

Create User Stories 

  • Assists the Scrum Team in creating User Stories and their Acceptance Criteria

Estimate User Stories 

  • Facilitates meetings of the Scrum Team to estimate User Stories 

Commit User Stories 

  • Facilitates meetings of the Scrum Team to commit User Stories

 Identify Tasks 

  • Facilitates the Scrum Team in creating the Task List for the next Sprint 

Estimate Tasks

  • Assists the Scrum Team in estimating the effort required to complete the tasks agreed to for the Sprint

Create Sprint Backlog

  • Assists the Scrum Team in developing the Sprint Backlog and the Sprint Burndown Chart

Create Deliverables 

  • Supports the Scrum Team in creating the Deliverables agreed to for the Sprint • Helps update the Scrum board and the Impediment Log

Conduct Daily Standup 

  • Ensures that the Scrum Board and the Impediment Log remain updated

 Groom Prioritized Product Backlog 

  • Facilitates Prioritized Product Backlog Review Meetings

Demonstrate and Validate Sprints 

  • Facilitates presentation of completed Deliverables by the Scrum Team for the Product Owner’s approval

 Retrospect Sprint 

  • Ensures that an ideal project environment exists for the Scrum Team in the succeeding Sprints 

Retrospect Project 

  • Represents the Scrum Core Team to provide lessons from the current project, if necessary

Processes 

Scrum Team Responsibilities

Form Scrum Team 

  • Provides inputs for the creation of the Collaboration Plan and the Team Building Plan

 Develop Epic(s)

  • Ensures a clear understanding of Epic(s) and Personas

Prioritized Product Backlog

  • Understands the User Stories in the Prioritized Product Backlog

 Conduct Release Planning

  • Agrees with other Scrum Core Team members on the Length of Sprint • Seeks clarification on new products or changes in the existing products, if any, in the refined Prioritized Product Backlog 

Create User Stories 

  • Provides inputs to the Product Owner on the creation of User Stories

Estimate User Stories

  • Estimates User Stories approved by the Product Owner

Commit User Stories 

  • Commits User Stories to be done in a Sprint

Identify Tasks 

  • Develops Task List based on agreed User Stories and dependencies

Estimate Tasks 

  • Estimates effort for tasks identified and if necessary updates the Task List

Create Sprint Backlog 

  • Develops the Sprint Backlog and the Sprint Burndown Chart

Create Deliverables 

  • Creates Deliverables • Identifies risks and implements risk mitigation actions, if any • Updates Impediment Log and dependencies

 Conduct Daily Standup 

  • Updates Burndown Chart, Scrum Board, and Impediment Log • Discusses issues faced by individual members and seeks solutions to motivate the team • Identifies risks, if any • Submits Change Requests if required

Groom Prioritized Product Backlog 

  • Participates in Prioritized Product Backlog Review Meetings

Demonstrate and Validate Sprints

 •Demonstrates completed deliverables to the Product Owner for approval

Retrospect Sprint

  • Identifies improvement opportunities, if any, from the current Sprint and agrees on any actionable improvements for the next Sprint

Retrospect Project 

  • Participates in Retrospective Project Meetings