Articles

A Scrum project often goes through a number of phases. Five phases, composed of nineteen processes, are suggested in A Guide to the Scrum Body of Knowledge (SBOK). The Release phase is the final stage of a Scrum project.

This phase includes two processes that emphasize delivering the Accepted Deliverables to the customer and identifying, documenting and internalizing the lessons learned during the project. It is important to note that the processes 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.

Ship Deliverables

In this process, all deliverables from the accepted User Stories of previously completed Sprints are delivered or transitioned to the relevant business stakeholders. A formal Working Deliverables Agreement documents the successful completion of the release. As new product increments are created, they are continually integrated into prior increments, so there is a potentially shippable product available at all times throughout the project. Ship Deliverables should include Working Deliverables Agreement, Working Deliverables, and Product Releases.

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 project releases. The primary responsibility of the Scrum Guidance Body is to ensure that the lessons learned in each project are not lost and are embedded in the organization. Additionally, the Scrum Guidance Body may provide expertise in various areas including Quality, HR and Scrum. When the initial Program Product Backlog or Prioritized Product Backlog are developed they are based on User Stories and required functionalities. Often, non-functional requirements may not be fully defined in the early stages of the project and can surface during the Sprint Review, Retrospect Sprint or Retrospect Release Meetings. These items should be added to the Program Product Backlog (for the program) and Prioritized Product Backlog (for the project) as they are discovered.

Executing the two processes of the Release phase ends a project in successful fashion—one that satisfies all parties involved. Remember that the processes do not need to be performed sequentially or separately. They can be adjusted to complement the specific requirements of each project. In the Release phase, assuming all of the prior phases of the project were followed, the Scrum Team can enjoy a job well done while keeping in mind lessons learned for future projects.

A Scrum project often goes through a number of phases. Five phases, composed of nineteen processes, are suggested in A Guide to the Scrum Body of Knowledge (SBOK). Regardless of the Scrum project, it needs to start somewhere—this is known as the Initiate phase.

The Initiate phase includes six processes that address the specific activities and flow of a Scrum project. It is important to note that the processes 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.

Create Project Vision

The Project Business Case is reviewed to create a Project Vision Statement that will serve as the inspiration and provide focus for the entire project. A good project vision should focus on the problem rather than the solution. The Project Vision Statement should not be too specific and should leave room for flexibility. The Product Owner is the person responsible for achieving maximum business value for the project and represents the Voice of the Customer in the Create Project Vision process.

Identify Scrum Master and Business Stakeholder(s)

The Scrum Master and Business Stakeholders are identified using specific Selection Criteria. A Scrum Master is a facilitator and “servant leader” who ensures that the Scrum Team works in an environment conducive to completing the project successfully. Business Stakeholders—customers, users, sponsors—frequently interface with the Scrum Core Team and influence the project throughout the product development process.

Form Scrum Team

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. The Scrum Team is a group of people who are responsible for understanding the business requirements specified by the Product Owner, estimating User Stories and creating the project deliverables. The team decides on the amount of work to commit to in a Sprint and determines the best way to perform the work.

Develop Epic(s)

The Project Vision Statement serves as the basis for developing Epics—large, unrefined User Stories in the Prioritized Product Backlog. User Group Meetings may be held to discuss appropriate Epics. Epics are written in the initial stages of the project when most User Stories are high-level functionalities and product descriptions and requirements are broadly defined. Once these Epics come up in the Prioritized Product Backlog for completion in an upcoming Sprint, they are 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 that can be completed in a Sprint.

Create Prioritized Product Backlog

Epics are refined, elaborated and then prioritized to create a Prioritized Product Backlog for the project. The Product Owner develops a Prioritized Product Backlog, which contains a prioritized list of business and project requirements written in the form of Epics. The Prioritized Product Backlog is based on three primary factors: value, risk or uncertainty and dependencies. The Done Criteria—a set of rules that are applicable to all User Stories—is also established in this process. A clear definition of Done removes ambiguity from requirements and helps the team adhere to mandatory quality norms. A User Story is considered Done when it is approved by the Product Owner who judges it on the basis of the Done Criteria and individual User Story Acceptance Criteria.

Conduct Release Planning

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 Product Owner and the Scrum Team decide on the Length of Sprint for the project, which often remains the same throughout the project. However, it may change if the Product Owner and Scrum Team decide that it is necessary or appropriate.

Following the six processes of the Initiate phase will lay a solid groundwork for any Scrum project. Remember that the processes do not need to be performed sequentially or separately. They can be adjusted to complement the specific requirements of each project. Before leaving the Initiative phase, however, it is imperative to create a good project vision and establish the various Scrum roles.

A Scrum project often goes through a number of phases. Five phases, composed of nineteen processes, are suggested in A Guide to the Scrum Body of Knowledge (SBOK). After the Initiate phase comes the Plan and Estimate phase.

This phase includes six processes related to planning and estimating tasks. It is important to note that the processes 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.

Create User Stories

IIn this process, User Stories and their related Acceptance Criteria are created by the Product Owner (elaborated from the previously-defined Epics) and incorporated into the Prioritized Product Backlog. User Stories are designed to ensure that the customer’s requirements are clearly depicted and can be fully understood by the business stakeholders. User Stories need to be tangible enough and must satisfy the Definition of Ready before they can be estimated and developed by the Scrum Team.

Estimate User Stories

In this process, the Scrum Team, supported by the Scrum Master, estimates the User Stories and identifies the effort required to develop the functionality described in each User Story. Only User Stories that satisfy the Definition of Ready and are properly defined by the Product Owner are estimated by the team.

Commit User Stories

In this process, the Scrum Team commits to delivering a set of User Stories for the Sprint. The decision on which User Stories will be committed to is based on the relative value-based priority of the User Stories and the estimated effort and team velocity for one Sprint. As part of this process, the Scrum Team starts the creation of the Sprint Backlog, which contains the committed User Stories that are assigned to a particular Sprint. The backlog is refined further with task-level details as Sprint Planning continues. With this commitment from the Scrum Team given at the beginning of a Sprint as part of 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 decomposed into specific tasks and compiled into a task list. Identifying tasks could either be done at the beginning of the Sprint for all committed User Stories or before the team starts working on the tasks required for each User Story. 

Estimate Tasks

This is an optional process which involves creating task estimates if the Scrum Team sees value in doing so. In this process, the Scrum Team estimates the effort required to accomplish each task in the Task List. Task estimates could either be determined at the beginning of the Sprint for all User Stories/tasks relevant to that Sprint, or for each task just before the team starts working on the particular User Story/task. The estimation can be done using the same methods that were used for the Estimate User Stories process.

Update Sprint Backlog

In this process, the Scrum Core Team updates the Sprint Backlog with task details and if available, the task estimates. The updated Sprint Backlog will be used in the Implement phase to track the team’s progress during the upcoming Sprint. Once the Sprint Backlog is finalized and committed to by the Scrum Team, new User Stories should not be added. That said, tasks that might have been missed or overlooked from the committed User Stories may need to 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.

Following the six processes of the Plan and Estimate phase will help make subsequent stages of the Scrum project a lot smoother. Remember that the processes do not need to be performed sequentially or separately. They can be adjusted to complement the specific requirements of each project. Before leaving the Plan and Estimate phase, however, it is imperative to develop a firm grasp of the tasks to be completed throughout the project.

A Scrum project often goes through a number of phases. Five phases, composed of nineteen processes, are suggested in A Guide to the Scrum Body of Knowledge (SBOK). After the Plan and Estimate phase comes the Implement phase.

This phase includes three processes related to the execution of tasks and activities—creating various deliverables, conducting Daily Standup Meetings, refining the Product Backlog at regular intervals—to create a project’s product. It is important to note that the processes 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.

Create Deliverables

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

Conduct Daily Standup

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

Refine Prioritized Product Backlog

In this process, the Prioritized Product Backlog is continuously updated and maintained. A Prioritized Product Backlog Review Meeting is held, in which any changes or updates to the backlog are discussed and incorporated into the Prioritized Product Backlog as appropriate.

Following the three processes of the Implement phase will guide effective execution of the project at hand. Remember that the processes do not need to be performed sequentially or separately. They can be adjusted to complement the specific requirements of each project. Before leaving the Implement phase, however, it is imperative to follow the blueprints of earlier phases to produce quality deliverables.

Understanding what Scrum of Scrums is and how it works in the product development process is very important. The first thing to know about Scrum of Scrums is that it acquires relevance only for large projects where several Scrum Teams are involved. In this process Scrum Team representatives convene for Scrum of Scrums Meetings at predetermined intervals or whenever required, to collaborate and track their respective progress, impediments, and dependencies across teams.

Normally, one member from each Scrum Team will represent his or her team in the Scrum of Scrums Meeting. In most cases, this is the Scrum Master, but at times someone else may represent the team. A single person may be nominated by the team to represent them in every Scrum of Scrums Meeting, or the representative may change over time, based on who can best fulfill the role depending on current issues and circumstances. Each person involved in the meeting should have the technical understanding to be able to identify instances in which teams could cause each other impediments or delays. Other important participants of Scrum of Scrums meeting include Chief Scrum Master and Chief Product Owner.

The primary purpose of the Scrum of Scrums meeting is to facilitate communication and progress tracking among multiple teams. The Chief Scrum Master, or any Scrum Master facilitating the meeting, can announce an agenda beforehand, allowing individual teams to prepare accordingly.

During these meetings, any impediments affecting one team that might impact others should be highlighted for discussion. Additionally, if a team identifies a large-scale issue, change, or risk that could influence other teams, it should be communicated at the Scrum of Scrums. Insights from the Retrospect Sprint process that could affect multiple teams can also be shared to enhance the meeting's effectiveness.

These meetings, though preferably brief, are usually not time-boxed to allow comprehensive information sharing among teams. A representative from each Scrum team provides updates on their team's status, facilitating a collaborative environment.

The Scrum of Scrums meeting is held at predetermined intervals or as needed by the Scrum teams. These sessions enable face-to-face information exchange, ensuring that issues, dependencies, and risks impacting multiple teams are closely monitored. This coordination helps teams working on a large project to better integrate their efforts. The Chief Scrum Master, or another facilitating Scrum Master, ensures an open and honest environment for sharing information and feedback among team representatives.

For larger projects involving numerous teams, multiple levels of these meetings may be necessary. Each representative provides updates from their team, typically answering four specific questions to ensure clarity and consistency in communication.

1. What has my team been working on since the last meeting?
2. What will my team do until the next meeting?
3. What were other teams counting on our team to finish that remains undone?
4. What is our team planning on doing that might affect other teams?

The answers to these four questions provide information that allows each team to clearly understand the work status of all other teams. It is recommended that a dedicated conference room be made available for the Scrum of Scrums Meeting, where all the Scrum Team Representatives are comfortable.

Some of the important outputs of the Scrum of Scrums meetings are: Coordination of work across multiple Scrum Teams. This is especially important when there are tasks involving inter-team dependencies. Incompatibilities and discrepancies between the work and deliverables of different teams are quickly exposed. This forum also gives teams the opportunity to showcase their achievements and give feedback to other teams.

By using Scrum of Scrums Meeting, there is collaboration across the organization as opposed to people working in closed teams concerned primarily with their individual responsibilities. The Scrum of Scrums Meeting is a forum where Scrum Team members have the opportunity to transparently discuss issues, impacting their project. The need to deliver every Sprint on time forces the teams to actively confront such issues early instead of postponing seeking resolution. This timely discussion and resolution of issues in the Scrum of Scrums Meeting greatly improve coordination between different Scrum Teams and also reduces the need for redesign and rework. Risks related to dependencies and delivery time tables are mitigated as well.