The Product Owner is involved with the other Team Members throughout the Sprint, but after the Sprint Planning meeting is completed, the Product Owner cannot add to the scope of the work being done during the Sprint. New Product Backlog Items, no matter how high their priority, must be put onto the Product Backlog for the team to look at in the next Sprint. This restriction is meant to allow the team to truly be focused and committed to the work of the Sprint and to allow them to make commitments and learn to keep them, thereby building trust. The Product Owner can, of course, collaborate on the details of the PBIs the team has chosen for the Sprint. If the Product Owner does indeed force a team to take on extra work during the Sprint, it breaks the focus of the team and can lead to the team’s failure to complete the work they planned.
The Product Owner controls the order of the items in the Product Backlog, but not how many are done each Sprint. Instead, the team decides how many to do. This decision is made in Sprint Planning and, of course, should be made in collaboration with the Product Owner, but ultimately the Product Owner must let the team freely decide how many items are planned. This freedom allows the team to be truly motivated and committed to the work as well as being collectively accountable for getting that work done. If the Product Owner forces a team to take on more work than it feels is within its capacity, then that dis-empowers the team, moves accountability for getting work done to the Product Owner, and completely dis-ables the team from getting to a high-performance state.
The Product Owner is responsible for the Return on Investment (ROI) of the Product. In order to manage that responsibility, the Product Owner needs to estimate how much financial benefit the Product Backlog Items for a specific Sprint will generate, and compare that to the effort of one Sprint’s worth of the Scrum Team’s labor. This calculation then allows the Product Owner to decide if a given Sprint is worth doing or if the Scrum Team should turn its attention to other work… possibly even a different product. If the Product Owner has these estimates, then it is possible for the Product Owner to maximize the ROI of the Scrum Team. When these estimates are missing, it is difficult to ensure that the Scrum Team is working on the best possible PBIs. In the worst case, the Product Owner will spend the Team’s time working on very low ROI items and cause substantial problems for the business.
The Product Owner is responsible for maintaining the Product Backlog. This includes its ordering in terms of value and effort, its clarity, and identification of what acceptance criteria apply to each Product Backlog Item. It is also very important for the Product Backlog to be ready for each Sprint Planning Meeting so that the team can select the Items for the current Sprint and break those down into tasks. If this is done, the team is able to create an effective Sprint Backlog where it can volunteer for tasks and achieve quick wins each day. If not, the team will likely take on the work of refining the Product Backlog during the Sprint Planning Meeting which is wasteful and not focused. Having a ready Product Backlog helps the team focus during its meetings and ask relevant questions to the Product Owner.
The Sprint Review is a key meeting for the team to improve the product. There are three main purposes of the Sprint Review: inspect how the last Sprint went with regards to the product; identify the items that are complete and order any potential changes; and, integrate those changes into the Product Backlog. This meeting aids the team in inspecting and adapting the entire product increment and how the team is progressing towards any deadlines. The Sprint Review is a check point that helps the Scrum Team to know the product’s current state, compare to its desired state, identify gaps, and take the needed steps to improve. This meeting is also where the Product Owner challenges the Scrum Team to look at the product clearly (it’s not just for the stakeholders!). When a Scrum Team refrains from having and participating in this essential meeting, the is team is likely to become a Scrum Team in name only without any of the far reaching benefits that many other Scrum Teams have experienced. A demonstration of the Product Backlog Items completed in the Sprint is often a part of this meeting.
The Definition of “Done” for a Scrum Team makes transparent how close the team’s work is coming to being shippable at the end of every Sprint. Expanding the Definition of “Done” until the team is able to ship their product increment every Sprint is a process that every Team Member helps advance. Team Members expand the Definition of “Done” by learning new skills, developing trust and gaining authority to do work, automating repetitive activities, and finding and eliminating wasteful activities. When every Team Member is systematically expanding the Definition of “Done”, the team builds its capacity to satisfy business needs without relying on outside people, groups or resources. If Team Members are not actively working on this, then many of the obstacles to becoming a high-performance team will not be discovered.
Product Backlog Items (PBIs) that are at the top of the Product Backlog (in other words, those which are to be done next), need to be small enough that the Scrum Team can comfortably complete all the work for them within a single Sprint. The Product Owner should be spending a little time every Sprint to split “large” PBIs into small PBIs. The Product Owner relies on the team to estimate if they are small enough. If the PBIs are not small enough then large problems can arise. Probably the most serious problem is that the Scrum Team may be unable to start and finish PBIs in a single Sprint which can seriously hinder the “inspect and adapt” process due to Sprint results that cannot be demonstrated in the Sprint Review. Almost as bad, incomplete work can leave a mess in the system if the Product Owner for some reason decides to change priorities and not complete work started in a previous Sprint. Finally, incomplete work dis-empowers the Product Owner from being able to make a business-based decision to ship or deploy the Team’s work at the end of the Sprint. A smaller problem that can arise from PBIs that are large is that the Team may not be able to fill their Sprint as effectively. One way to think about this is the difference in how much empty space there is in a cup filled with large pebbles versus a cup filled with sand. The rule of thumb is that PBIs should be small enough that between five and ten fit into every Sprint. This is often the right compromise between the effort required on the part of the Product Owner to write small PBIs and the risks mentioned above.
The Scrum Team plans their work in the Sprint Planning meeting and that planned scope (Product Backlog Items) is meant to be respected… it is a commitment by the team. In exchange for that commitment, the rest of the organization commits to leaving the team alone to focus on its work. Focus and commitment are both important values of Scrum. Any interruption to any individual Team Member except the ScrumMaster and Product Owner is considered a cause for relieving the Team of its commitment. This rule of Scrum is designed to put pressure on the organization to leave the team to focus on the most valuable work. If the organization allows interruptions to the team’s work during the Sprint, then the team will not meet its commitments and this will diminish trust between the team and its stakeholders. That lack of trust will lead to onerous control mechanisms that reduce the team’s ability to self-organize which, in turn, will prevent the team from becoming a high-performance team.
After a team finishes its Sprint Review, the Retrospective meeting should begin immediately. Of course, there may be a small transition period as non-team members leave a meeting room or as the Team Members go back to their team room. However, there should be no work on the system done between Sprint Review and Retrospective. This quick transition between the two meetings is primarily to ensure that everyone has a clear memory of the Sprint. If there is a gap between the two meetings it can lead to a number of sub-optimal behaviours: team members may do work without the knowledge of the rest of the team, there may be a growing desire to delay the retrospective, or even pressure to skip the retrospective.
Timeboxing is the practice of ending a meeting exactly on time regardless of the state of discussion or the desire of participants. In Scrum, the combined length of the Sprint Review and Retrospective Meetings is determined by the length of the Sprint. For example, a one week long Sprint has Sprint Review and Retrospective Meetings that are timeboxed to two hours in total. It is acceptable for the meetings to take less time, but not more. A two week long Sprint has a Sprint Planning Meeting that is timeboxed to four hours. Keeping the Sprint Review and Retrospective Meetings timeboxed has two beneficial effects: one, the team keeps the overhead dedicated to meetings to a relatively low level, and two, the team learns to do effective inspect and adapt in a very short period of time. If the meetings are not timeboxed, then typically the team will keep going until they are “done”… and break the timebox of the overall Sprint.
The last part of the Sprint is the Sprint Retrospective. This meeting is a private meeting for the members of the Scrum Team (including the ScrumMaster and Product Owner). In this meeting, the Team Members discuss how they did their work during the past Sprint and come up with ways to improve their work in the next Sprint. Scrum does not define any particular techniques to use during the Retrospective meeting. The Retrospective is complementary to the Sprint Review. The Review inspects “what” was done and the Retrospective inspects “how” it was done. The Sprint Retrospective is critical for the team to apply the principle of “inspect and adapt” that is core to Scrum. Missing the Sprint Retrospective is a critical failure of the ScrumMaster’s job to ensure that the principles of Scrum are being used. If a Retrospective is missed once, what may happen is that some Team Members might feel that missing it was not so bad. There will not likely be any immediate consequences to missing the Retrospective. However, the attitude that the Retrospective is not important will be implanted in the team. This then quickly leads to further compromises and eventually, the continuous improvement parts of Scrum are abandoned and the team focuses purely on the execution parts of Scrum. The team will then fail to become a high-performance team since that high-performance state is predicated on systematic, conscious self-improvement of how the team does its work.
Scrum is a tool for product development that uses transparency and fast feedback. The Sprint Review is an open meeting during which the Scrum Team works with all interested stakeholders to look at the results of the Sprint. This meeting is usually dominated by a demonstration of the working increment of software. The stakeholders in attendance at this meeting freely provide feedback about the product which is then used by the Product Owner to update the Product Backlog. This feedback is critical to ensure that the team is staying on-track, that it is building the most valuable possible product features, and that the stakeholders are satisfied with the results. Missing this aspect of feedback makes Scrum only modestly better than non-agile approaches to doing work and should be considered a critical problem to fix as it undermines the whole point of doing Scrum.
Timeboxing is the practice of ending a meeting exactly on time regardless of the state of discussion or the desire of participants. In Scrum, the length of the Sprint Planning Meeting is determined by the length of the Sprint. For example, a one week long Sprint has a Sprint Planning Meeting that is timeboxed to two hours. It is acceptable for the meeting to take less time, but not more. A two week long Sprint has a Sprint Planning Meeting that is timeboxed to four hours. Keeping the Sprint Planning Meeting timeboxed has two beneficial effects: one, the team keeps the overhead dedicated to meetings to a relatively low level, and two, the team learns to do effective planning in a very short period of time. If the meeting is not timeboxed, then typically the team will keep planning until the plan is “done” which usually substantially eats into work time.
The Sprint Planning meeting is the start of the Sprint and is the opportunity for the Scrum Team to discuss what they will build during the Sprint and how they will build it. The focus of the meeting is on choosing Product Backlog Items (the goal for the Sprint) and then breaking those Backlog Items down into a detailed list of tasks (the Sprint Backlog). In Sprint Planning, choosing who will do the work is strongly discouraged. The value of Sprint Planning comes at three levels: first, setting a concrete goal helps with team cohesion and enables high-performance teamwork, second, the planning work helps set expectations with stakeholders and develop a team’s understanding of its own capacity, and third, the time set aside for planning gives the team a chance to think systematically about how to respond to feedback from the previous Sprint.
The length of a Sprint determines how quickly a Scrum Team can “inspect and adapt” to changing circumstances and learning. Scrum, as a tool for product development, sets an upper limit to the duration of a Sprint. In other words, Scrum sets a minimum for the frequency of the inspect and adapt cycle. This ensures that teams using Scrum get at least a certain minimum benefit. Scrum does not set a maximum frequency (minimum Sprint length). If a team has a five-week (or longer) Sprint, the benefits from Scrum rapidly drop off. In particular, you dramatically increase risks associated with short term planning, responding to change, team development, windows of business opportunity, and error detection. Having a cycle longer than four weeks is not Scrum and a team with such a cycle length should not claim to be using Scrum.