Working with Story Points, Velocity, and Burndowns
The best we can do is size up the chances, calculate the risks involved, estimate our ability to deal with them, and then make our plans with confidence.
—Henry Ford
Within an Agile context, applying story points is an acknowledged way to size user stories. Story points are a relative sizing approach that focuses on the scope of work, which is made up of the effort of the work and its complexity. As a readiness activity within the RICH model, it is important to educate team members on the sizing framework you are applying, using Sprint Burndowns to assess progress within a Sprint, and how velocity can help you establish the team pace of work.
Scope versus Schedule Measure
When I help teams implement agile methods, some team members have a hard time getting their head around “estimating” user stories using story points. This has to do with understanding the relative sizing that story points bring. Some team members (including management) ask to align story points with days or hours. I realized that when I use the word estimate it brings the baggage of traditional estimation that uses schedule as a measure (hours, days, weeks, months, years).
With this in mind, I strongly advocate that in Agile it is appropriate to use the term “size” to measure user stories because this relates to the amount of functionality being built. This is more than just semantics. This takes us a step away from the traditional mindset where schedule is king and moves us to the more important focus of scope—because to our customers the functionality is what is valuable and what they pay for. There will always be trade-offs between schedule and scope, but working software that meets the scope of customer needs and provides them value is slightly more important (working software over schedule).
Agile Pit Stop Story points are an abstract scope measure focusing on the work. It is not wise to apply a schedule measure of hours and days. Instead, use a scope measure like story points to indicate the amount and complexity of the work.
In Agile, the intent is to determine the unit size of work based on the functionality you are building for that story. In effect, scope is the measure of progress based on amount of effort and complexity of the work. I realized that there are those who try to apply a schedule measure because of their familiarity with traditional estimation whereas story points are in fact meant to represent the scope of the work. In other words, when you try to apply a schedule measure for scope, it is like trying to fit a square peg in a round hole. Ultimately, you need both scope (story points) and schedule (per Sprint length) to understand your team pace (velocity).
Story Points
Story points are a relative measure that expresses the amount of functionality and the complexity of the work. Every team creates their own story point sizing framework based on the type of work they do, the skills and experience of the team, and what they personally perceive to be a small, medium, or large amount of work. This is why management should not compare the story point velocity of different teams.
This relative sizing framework takes the focus off the actual schedule measure of hours or days and instead puts it on describing the size and complexity of a functionality compared with other functionality. If you are familiar with function points, story points acts as a similar measure that tries to establish a unit size or scope of the work.
Agile Pit Stop Story point sizing framework is specific to each team. This is why no one should try to compare the story point sizes from one team to the next.
Fibonacci Sequence
Story points are usually expressed in numeric units. The range of units that is often used within the agile world is the Fibonacci sequence. The sequence of Fibonacci numbers provides a numeric distribution that can be used to differentiate between sizes of work (Figure 19-1).
Figure 19-1. Fibonacci sequence that highlights a substantial distribution of numbers
This sequence is established where each subsequent number is the sum of the two numbers immediately before it. The importance of the Fibonacci sequence to the team is that it provides a means for differentiating between unit sizes of functionality being built from the stories within the backlog.
Establishing Relative Story Point Sizing Framework
Story points start as an abstract scope measure until such time as a team establishes a team-based relative sizing framework according to a numerical range, in this case the Fibonacci sequence. The team defines what it means to build the smallest amount of functionality that can stand on its own. For example, the team defines a story point size of a 1 as follows:
- Build a static webpage with fixed content using HTML.
From there, the team can determine what type of work is considered twice as large with minimal functionality or almost twice as large but with slightly more complexity. This would receive a story point size of 2. You may decide up front what work defines a story point size of 3, 5, 8, 13, and 21 to help you size user stories, or you may use what you define as 1 and 2 as the basis for sizing all other work and extrapolating the size from there.
Agile Pit Stop This relative story point sizing framework should be in a readily viewable place for all of the team to see.
This is the beginning of establishing the relative story point sizing framework for your team. Because each Scrum Team may work on different types of functionality (for example, front-end UI versus back-end database), it is critical that each team develop their own sizing framework.
Planning Poker
Planning poker is an instructive and fun consensus-based sizing technique used to size the stories, primarily during Sprint Planning. It is based on Wideband Delphi, a consensus-based technique for sizing work. Planning poker starts with placing the Fibonacci sequence numbers from 1 through 55 on the faces of playing cards (Figure 19-2).
Figure 19-2. Planning poker playing cards used to size user stories
To play planning poker, each team member gets a deck of cards. For this example, Sprint Planning has commenced and the team has discussed the details of a user story. When it is time to size the story:
- Each team member discreetly selects a card from their deck relating to the story points they think reflects the size and complexity of the work for the story and simultaneously displays it to the rest of the team.
- If there is consensus in the size, this becomes the recorded size for the story.
- If there are differences in sizes, then the owners of lowest and highest cards explain their sizing position, and the team briefly discusses the story further.
- Each team member again selects a card based on the new discussion.
- This continues until a consensus on the size is achieved.
Planning poker can be played face to face when all team members are colocated or virtually when team members are distributed. If virtual, then sizes can be instant-messaged to the Scrum Master, who shares the sizes with the team.
Sprint Burndown
A Sprint Burndown is used by a team to highlight the amount of work that a team plans to complete, known as the target velocity, compared to what work was actually completed and what work is left to do. It is a metric meant only for a particular Scrum Team and is only relevant for a particular Sprint. The benefit is that it is used to provide a team awareness of whether they are on track, predict when all of the work will be completed, and identify roadblocks early.
In Figure 19-3, the ideal burndown line starts with the team’s target velocity, which is the amount of work a team believes they can do within a Sprint. In this example, the unit of work is called story points and for this Sprint the target velocity is 55. The ideal burndown line is established by starting with the target velocity and then subtracting the average increment each day. You get the daily average increment by dividing the target velocity by the number of days in a Sprint (in this example, 55/10 = 5.5).
Figure 19-3. Sprint Burndown to help a team view their progress throughout a Sprint
The actual burndown line indicates how many story points of work are actually completed from day to day. It starts with the team’s target velocity (55), and each day it is subtracted by the amount of work done or completed stories each day. Because each story is a different size, the amount that gets subtracted on each day varies by the number of stories and the unit size of each of those stories. (Don’t be surprised if, early in the Sprint, the actual burndown stays flat for a couple of days. Team members are just starting the work and it is not realistic to expect immediate completion of a story.)
Velocity
Velocity is a metric that can help you understand a team’s sustainable pace by identifying the amount of stories that represent customer value a team can deliver in a Sprint. Sustainable pace is one of the Agile principles, and the intent is to understand this pace when team members are working 40 hours a week and no more. Sustainable pace allows team members to work indefinitely. A team’s Sprint velocity is a representation of how many story points of functionality a team can deliver within a Sprint. At the beginning of a Sprint, it is called the target velocity. The actual velocity is calculated at the end of each Sprint based on the stories that actually get completed that meet the done criteria (Chapter 20) and the acceptance criteria of each story (Chapter 18).
A team’s velocity is commonly represented in graphical form that is used to measure the rate of business value a team can consistently deliver from Sprint to Sprint. Because each team applies its own relative story point sizing framework, this metric is unique and only applicable for a particular team. It must not be used to compare one team to another. The benefit is that over time, it becomes a predictor of the amount of work a team can do in the subsequent Sprint.
In Figure 19-4, the target velocity is the team’s estimate of how many units of work (or story points) it thinks it can complete within a Sprint. The actual velocity is the actual units of work completed in that Sprint. The average velocity is the average of the actual velocities accrued divided by the number of Sprints completed.
Figure 19-4. Team velocity metrics that a team uses to predict their target velocity (number of story points they can complete in a Sprint)
Notice in the first Sprint that the team estimated a target velocity of 75. Because they did not have any historical data on which to base their velocity, it was a guess. They learned at the end of the Sprint that they actually completed 40 story point units of work. The good news is that at the beginning of the next Sprint, they have a basis of actual work completed as historical data, which can help them predict with more accuracy how many story points of work they can complete. You can see by Sprint 4, the average velocity of 52 story points becomes a fairly accurate predictor of how much work the team can complete in Sprint 5, during which they actually completed 55 units of work. The velocity helps set a realistic target of work for each Sprint and can be used to provide a release burnup for how many story points can be completed for release (see discussion in Chapter 14).
Are You Getting the Point?
As teams get ready to implement Agile, it is important for them to establish a sizing framework they will apply, use Sprint Burndowns to assess progress within a Sprint, and understand how velocity can help them establish a sustainable team pace of work. Story points provide an abstract unit measure of work that becomes specific to a team when they establish their relative story point sizing framework.
This sizing framework is very important for a team to achieve a sustainable pace of work at 40 hours a week and no more to avoid team member burnout and gain alignment with the Agile principles. To achieve a sustainable pace, you need to track your team velocity, which is the scope quantity (story points) per unit time (Sprint length). Establishing a sizing framework can help a team achieve a sustainable pace throughout the project.