Scrum Phases and Processes (Project Lifecycle)
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.
Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.
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.
Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.
b) Identify Scrum Master and Stakeholder(s)
—In this process, the Scrum Master and Stakeholders are identified using specific Selection Criteria.
Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.
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.
Note - Asterisks (*) denote a “mandatory” input, tool, or output for the corresponding process.
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.
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.
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.
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.
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.
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.
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
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.
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 |
|
Identify Scrum Master and Stakeholder(s) |
|
Form Scrum Team |
|
Develop Epic(s) |
|
Create Prioritized Product Backlog |
|
Conduct Release Planning |
|
Create User Stories |
|
Estimate User Stories |
|
Commit User Stories |
|
Identify Tasks |
|
Estimate Tasks |
|
Create Sprint Backlog |
|
Create Deliverables |
|
Groom Prioritized Product Backlog |
|
Demonstrate and Validate Sprints |
|
Ship Deliverables |
|
Retrospect Project/Sprint |
|
Processes | Scrum Master Responsibilities |
Identify Scrum Master and Stakeholder(s) |
|
Form Scrum Team |
|
Develop Epic(s) |
|
Create Prioritized Product Backlog |
|
Conduct Release Planning |
|
Create User Stories |
|
Estimate User Stories |
|
Commit User Stories |
|
Identify Tasks |
|
Estimate Tasks |
|
Create Sprint Backlog |
|
Create Deliverables |
|
Conduct Daily Standup |
|
Groom Prioritized Product Backlog |
|
Demonstrate and Validate Sprints |
|
Retrospect Sprint |
|
Retrospect Project |
|
Processes | Scrum Team Responsibilities |
Form Scrum Team |
|
Develop Epic(s) |
|
Prioritized Product Backlog |
|
Conduct Release Planning |
|
Create User Stories |
|
Estimate User Stories |
|
Commit User Stories |
|
Identify Tasks |
|
Estimate Tasks |
|
Create Sprint Backlog |
|
Create Deliverables |
|
Conduct Daily Standup |
|
Groom Prioritized Product Backlog |
|
Demonstrate and Validate Sprints | •Demonstrates completed deliverables to the Product Owner for approval |
Retrospect Sprint |
|
Retrospect Project |
|