The core of Scrum, occasionally referred to as the "Game", describes how to prepare and run Sprints. While not officially described as such in the Scrum Guide, the phases of a Scrum project cycle could be considered and are sometimes described as Pre-Game, Game, and Post-Game.
In the first phase, the Product Owner defines the Project's Goal and develops the initial Product Backlog. The Product Backlog will continue to be updated as additional or modified requirements emerge during the project. Scrum development work is done during the actual development or Game Phase, where the product is built, inspected, and adapted using an iterative process. Each sprint produces a potentially releasable product which the customer may or may not decide to release at the completion of a sprint phase.
Pre-Game Phase
The Pre-Game phase includes two activities – 1. planning and 2. the development of the product's high-level design/architecture.
During planning, the Product Owner, with the help of the customer, identifies the most important requirements of the product that's to be developed. The decisions are based on what the market demands and on what customers believe will provide the most value for their organizations. The Product Owner captures these requirements in the 1. Project's Goal and the 2. Product Backlog.
1.Goal
During planning, the Product Owner and customer work together to define the product vision and Goal. Initially, some of the details might not be perfectly clear, but it's the Product Owner's responsibility to provide the team with a well-defined, comprehensive product goal.
The specific details of required product features and functionality can be refined as the project progresses but the team must have a concrete goal to refined as the project progresses but the team must have a concrete goal to work towards.
The project goal needs to reflect the vision for the project and relate to how the customer hopes the product will meet a business need and maximize its return on investment, or ROI.
2. Product Backlog
The Product Owner and the customer develop a list of prioritized requirements, known as the Product Backlog. Developers will determine what functionality they need to develop to meet these requirements.
The Product Owner maintains the Product Backlog throughout the course of the project and updates it as requirements change or are updated.
Also during initial planning, the Product Owner identifies the required release dates, works on the overall budget, and identifies risk control measures. The Product Owner also determines what team members and tools may be needed to develop the product.
Once pre-planning completes, it may be necessary to perform some Pre-Game design as well. This will depend on the nature of the product or service being developed. When required, the Development Team creates the product's high-level design, which describes the product's structure and behavior.
The team identifies the changes it needs to make to an existing system or architecture and identifies any problems it may encounter as a result of the new product or functionality. It then resolves these problems and integrates the solutions into a finalized high-level design.
For example, a Development Team is creating a high-level design for custom accounting software. It analyzes the company's current network to establish ways in which to integrate the software and ensure it performs optimally.
Although these Pre-Game activities are performed to develop the initial product backlog, the product backlog - once created - continues to evolve on an iterative basis from this point on. It is revised based on emerging product requirements, prior to each additional Sprint phase.
The Game Phase
The Game Phase refers to the Sprint, or development, phase. This is when the Development Team plans each Sprint and proceeds to create functioning product deliverables, also called potentially shippable product increments. At the end of each Sprint, the team delivers the results to the Product Owner for potential release. Feedback received is then cycled back into the process and used to Refine the Product Backlog for the next Sprint Planning activity.
During the Sprint Planning meeting, which takes place at the start of a Sprint, the Product Owner identifies which requirements from the Product Backlog the team must focus on meeting during the upcoming Sprint. The requirements with the highest value to the customer need to be selected first.
During this phase, the Development Team: 1. Formulates a Sprint Goal, 2. Develops the Sprint Backlog, and 3. Estimates the Tasks it has to complete during the Sprint.
1. Formulate a Sprint Goal
With the help of the Product Owner, the Development Team formulates the Sprint Goal, which is a description of what it needs to achieve during the Sprint. This serves as a commitment from the team to a specific outcome. For example, a Sprint Goal could be "to develop a user interface that will allow users to search a film database according to genre, year, and director."
2. Develop the Sprint Backlog
The Development Team determines the tasks that need to be completed in order to develop the selected backlog items and compiles these to form the Sprint Backlog – a list of finalized backlog items and corresponding tasks to be developed during the Sprint.
3. Estimate Tasks
Once the Development Team divides each backlog item into tasks and has defined the Sprint Goal, it estimates the effort it should take to complete each task.
If the Development Team needs to make changes to the Sprint Backlog or the Sprint Goal during development, it discusses options with the Product Owner, who can approve the changes. For example, the Development Team may not need to perform all the tasks in the Sprint Backlog to meet a Sprint Goal.
Generally, however, changes to the Sprint Backlog and work currently in development are avoided, unless a high-priority change or omission is identified. In most cases, additional items are added to the next Sprint.
An actual Sprint may last between 2 to 3 weeks. During this time, the Development Team creates the actual deliverables with the ultimate goal of developing a potentially shippable product increment every single Sprint.
A key factor in determining if a feature is potentially shippable is the team's Definition of Done. At minimum, functionality should be considered as done after being developed and fully tested against all other completed backlog items, including previously released product increments.
During a Sprint, the entire Scrum team meets at the same time each day for a 15-minute Daily Scrum. Historically, The Development Team uses this time to discuss the events of the previous 24 hours, what needs to be done over the next 24 hours, and possible solutions to any impediments that have arisen. Note: These specific questions are not part of the revised Scrum Guide as of November 2020. The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.
At the end of a Sprint, the Scrum team organizes two meetings. The Development Team invites stakeholders to a Sprint Review meeting, during which stakeholders inspect the functioning deliverables and provide feedback. Also, the ScrumMaster invites the Development Team to attend a Sprint Retrospective, during which they discuss ways to improve future Sprints.
A key activity performed during the execution of a sprint is the Refinement of the Product Backlog. During this activity, the Product Owner and Development Team clarify and evaluate Product Backlog items based on the latest feedback.
Items may be reordered, added or removed, split or combined, and re-prioritized based on the latest requirements and product feedback. The Development Team also estimates Product Backlog items as part of Product Backlog Refinement.
All these activities – planning a Sprint, executing it, reviewing the results, and Refining the Product Backlog – are repeated until all the customer's requirements have been met or an agreed deadline has been reached.
The Post Game Phase
The work needed after a Sprint or series of Sprints to release the product, is sometimes referred to as the Post-Game Phase.
The goal of each Sprint is to produce a releasable product increment. Depending on the nature of the product, the customer may release the latest developed functionality after each Sprint.
In some cases, the product may be released at specific release intervals after a series of Sprints, and in other cases the entire Product Backlog needs to be delivered before the final product is released.
However, Scrum development demands that at the end of each and every Sprint, a functioning product can be handed over to the customer. This means that when Scrum is implemented correctly, there is no Post-Game Phase. This is because every Sprint delivers production-ready product and thus no additional work is needed to release the work.
However, if a product has multiple releases, the project is not yet in closure and work continues towards the next release. In some of these projects, closure tasks, such as creating documentation or integration testing, may be listed as a backlog item to be completed as part of the Sprint Goal.
For example, a Scrum Team develops a database for an online shopping portal. The customer reviews it at the end of the Sprint and decides to release this feature before the functionality that supports international payments is in place. The Product Owner then reorders the Product Backlog and asks the team to test the database during the next Sprint.
Assessment: Match the project activities with the phases in which they occur. More than one activity may match to each phase.
Options:
A. Define the Project's Goal.