Every sprint starts with an event during which the work to be done is agreed on by all parties. A goal for the sprint is set, the scope of the sprint work is agreed on, and a plan for creating the PBIs is formed. This event is known as the Sprint Planning Meeting .
Defining the Sprint Goal
The Sprint Goal is a brief, high-level statement of the overall purpose of a sprint. It needs to be short, to the point, and clear. It is the completion of the sentence: We’re choosing this work for this sprint because . . . . It is the answer to the question: Why did we choose these particular PBIs to work on this time?”
We wish to create a minimum viable product (MVP) version to use to get beta customer feedback.
We wish to use this sprint to finish implementing all the back-end APIs.
We wish to finish the customer-facing portions of the user interface.
The sprint goal is important for two reasons. First of all, it provides focus and clarity for both the Product Owner and the Development Team when making day-to-day decisions. When developers, for instance, have to choose whether to spend the time necessary to fully “polish” a customer-facing screen, it is important to understand whether the goal is to create an MVP.
The second reason the Sprint Goal is important is that it provides the only way a sprint may be canceled before its time-box expires. The Scrum Guide states that the Product Owner may cancel a sprint if the sprint goal becomes “obsolete.” In other words, a sprint may be canceled if the point of the sprint no longer has any value. For example, it makes no sense to continue a sprint to create an MVP if one is no longer needed.
The first part of a sprint planning meeting includes a negotiation and agreement about the sprint goal. Agreement must be reached between the Product Owner and the Development Team (with the help of the Scrum Master, if necessary).
Selecting PBIs
After the sprint goal is established, the Product Owner and the developers inspect the Product Backlog. They select and discuss PBIs that will help achieve the sprint goal. The Product Owner provides input about the nature of the problem to be solved and its relative importance from the business’s point of view. The Development Team provides input about the relative difficulty of implementing the PBIs from a technical point of view and about any technical dependencies among the items. At the end of the meeting, the Product Owner and the developers will have agreed on a set of items that will deliver the most value possible and will be practical to implement within the constraints of that sprint.
When this agreement is reached it remains unchanged throughout the sprint unless both the Product Owner and the Development Team agree to change it. The Product Owner agrees the work will be limited to the specified PBIs. The developers agree to resolve the PBIs and demonstrate the solutions at the end of the sprint.
Creating the Sprint Backlog
After the scope of the sprint has been agreed on, the Product Owner leaves the Sprint Planning Meeting and the development team members get to work. Their purpose is to create a work plan for implementing the PBIs they have just agreed to undertake. PBIs are descriptions of problems to solve; therefore, the Development Team plans out the solutions as a set of technical tasks to perform. The PBIs and the list of technical tasks necessary to solve them are known as the Sprint Backlog.
Understanding the Development Team’s Capacity
- 1.
What are the sizes of the PBIs? How much team capacity will each one take?
- 2.
What is the team’s capacity to do this work? How much work can it take on before the work becomes “too much?”
The theory of Empirical Process Control states that decisions should be based on measurements rather than predictions. Therefore, a Development Team’s capacity should be established through measurements. A team should do some work and then measure how much work actually got done to figure out its capacity.
The measured amount of work a team gets done during a sprint is called the team’s velocity. If a team’s velocity is known, then it can be compared to the amount of work represented by the PBIs. Good decisions can then be made by the developers during the Sprint Planning Meeting with regard to what they should attempt to accomplish.
So all that is necessary is for the team to figure out how much work each PBI represents. When it has done that, it can work on those items and measure how much it can get done in a sprint.
Unfortunately, figuring out the size of a PBI is tricky. The Scrum Guide mentions a concept called “units of work,” but does not define it. To measure something, a unit of measure is required. What is the correct unit of measure for the size of a PBI?
Some people maintain that the proper unit of measure to use is man-hours of effort. Estimates of the number of man-hours required to implement PBIs can be made and used to gauge how many PBIs will fill a team’s capacity.
Whose man-hours should be used? On any given team, there are different members with different levels of skill. A task that takes an experienced developer only a few hours to perform might take a novice considerably more time to do. Should the size of the PBI depend on which team member will do the work?
The number of man-hours in a sprint is a fixed quantity. If there are five developers and the sprints are two weeks long, then there are 50 man-days in that sprint. If the sizes of PBIs are expressed in man-hours (or man-days), then the velocity of the team will always be the same. It will always work out to 50 man-days.
Man-hours are measures of effort. Velocity should be a measure of the team’s ability to produce results with that effort. Asking “How many man-days worth of work can be accomplished in 50 man-days?” is not very useful (the answer is always 50). Asking “How much result can be accomplished in 50 man-days?” is much more useful to know.
As can be seen, the size of PBIs should be expressed in terms of results rather than effort.
Unfortunately, there is no standardized unit of measure for these results. Man-hours, lines of code, and file size are all measures of effort. Simply counting the PBIs only makes sense if they are all about the same size. If there are big ones and small ones, then counting them does not work.
There is no objective absolute unit of measure that can be used to give sizes to the results produced by a Scrum Team. If we want to measure the length of something, we have yardsticks marked off in inches to do it. If we want to measure the weight of something, we have scales marked off in kilograms to do it. If we want to measure the temperature of something, we have thermometers marked off in degrees to do it. There is no yardstick or scale or thermometer we can use to measure the size of the results produced by a team. There is just no such unit of measure.
Story Points
Although there is no absolute unit of measure relating to the size of a result, we can still measure relative sizes to some extent. Let’s say that one team of five inexperienced people works hard over the course of a ten-day sprint and produce a pop-up window that says “Hello World.” Let’s also say that another more experienced team of five developers works hard over the course of a ten-day sprint and produces an entire app. The effort of each team is the same (50 man-days), but the result is different. We don’t know exactly how big the difference is, but we do know the experienced team produced more result than the inexperienced team.
Let’s say that during the next sprint the inexperienced team was able to produce 25% of a complete app. This is more than they produced before, but still less than the experienced team. Let’s also say that a third team produced 50% of an entire app. This is more than the inexperienced team’s 25%, but less than the experienced team’s 100%.
Smallest: “Hello World” window
Larger: 25% of an app
Larger: 50% of an app
Largest: 100% of an app.
We could then arbitrarily assign a size of 1 point to the smallest result, a size of 20 points to the largest result, and then prorate the sizes of the other results (meaning, 5 points to the 25% result and 10 points for the 50% result). We could then figure out the sizes of other tasks by comparing them to these basic benchmarks.
The arbitrary numbers we assign to these results are called story points. After they are calibrated to actual work that has been performed, the Development Team can use them to assign sizes to items in the Product Backlog. The developers can consider an item in the Product Backlog and might, for example, have the following thought process: Is this bigger than 50% of an app but smaller than 100% of an app? If so, it is between 10 story points and 20 story points. This one feels like a 14-point story.
It is common for the Development Team to start writing down the technical tasks required to implement the story while they figure out its size.
Product Backlog Refinement
The process of assigning sizes to PBIs and writing down the technical steps needed to implement them is called product backlog refinement. Before the Development Team can select items to include in a sprint’s scope, the items must be “refined” so that the developers know what they are saying yes to.
Product Backlog Refinement can be done during the Sprint Planning Meeting. The time-box for the Sprint Planning Meeting is the longest one other than the time-box of the Sprint itself. For a month-long sprint, the time-box of the Sprint Planning Meeting is eight hours. A full day is set aside to allow the Scrum Team to agree on a scope and create a Sprint Backlog for getting the scope done.
The time-box is long enough to allow ample time for product backlog refinement activities to occur. Enough PBIs must have been refined before the end of the meeting to make up at least the current sprint’s scope. The eight-hour time-box provides ample time for the refining to take place during the Sprint Planning Meeting if it hasn’t been taken care of beforehand.
It is a good idea to take care of some or all of this refining before the Sprint Planning Meeting takes place. The Scrum Guide recommends that up to 10% of each sprint be set aside for refining PBIs for future sprints.
It is common practice to schedule two to three product backlog refinement meetings during each sprint. Some people worry that two to three meetings on top of an eight-hour Sprint Planning Meeting seems like quite a bit of time to spend on refinement.
It is important to realize, however, that the amount of refining doesn’t necessarily increase. The timing of the activity is what gets affected. If the developers and the Product Owner go into a sprint planning meeting in which everyone already understands the PBIs, their size, and the technical tasks they require, there is no reason the Sprint Planning Meeting should take very long at all. The entire event can be over in five minutes if proper preparations are made.
During the Sprint Planning Meeting, the Product Backlog is inspected and the Sprint Backlog is created. If the event is done properly, the Product Owner leaves with a promise from the developers that they will deliver a specific set of PBIs by the end of the sprint. The developers enter into this bargain freely because they chose the PBIs and thus feel accountable for completing them.
Summary
The Sprint Planning Meeting is, in many ways, the heart of the Scrum Framework’s sprint cycle. It is where self-organization and cross-functionality matter the most. This is a meeting during which the business side of things and the technical side of things get together to figure out how to move forward.
The Product Owner, representing the business, lays out the needs of the product and identifies the most pressing and important ones. The Development Team, representing the technical side, examines the technical challenges involved in meeting those needs and identifies a specific set of PBIs to accomplish them. The Product Owner and the Development Team negotiate over the set of items to be delivered. When agreement is reached, the work of the sprint begins.