How to plan your Sprint with Story Points
2020/09/30
Every Sprint Planning, Scrum teams face the challenge of estimating in advance the development effort of the User Stories to be implemented. In this post we will show you how Story Points can help and what to consider when estimating with Story Points.
Why should the effort of User Stories be estimated at all?
The Product Owner is responsible for prioritizing the backlog but he usually cannot estimate the effort required to implement individual User Stories himself, as the technical knowledge for this is often lacking. For this reason, the developers in the team collaboratively estimate the effort required and thus help the Product Owner to develop a better understanding of the User Stories and, if necessary, to eliminate any ambiguities. For example, an estimation can reveal that a User Story is too large and should better be broken down into smaller User Stories or that the acceptance criteria need to be formulated more precisely.
Basically, this procedure has two goals:
The team finds out how much work it can do in a Sprint. The amount of work a team can do per Sprint is also called “velocity” and becomes apparent after only a few Sprints.
A backlog in which a sufficient number of User Stories have been estimated allows long-term planning over several Sprints, e.g. for release planning.
However, it is important for all parties involved—including customers—to remember that estimates are always associated with uncertainty.
What are Story Points?
But how exactly is the required effort of User Stories estimated? Each User Story is assigned a value on a predefined scale. The so-called “modified Fibonacci sequence” is the most commonly used scale for this purpose and consists of the Story Points 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100. However, some teams also use other abstract scales, such as T-shirt sizes (S, M, L, XL, etc.) or animals (ant, mouse, cat, lion, elephant, blue whale).
At this point it is important to emphasize that Story Points do not reflect the amount of time required for the implementation. Therefore, it’s not estimated in hours! Instead, various factors are included in the estimate: size, complexity, risk, and uncertainty. For example, a major new feature that is not yet clearly defined may cause unforeseen (technical) difficulties during the implementation, which is why the team would be more likely to rate such a user story with a high Story Point value.
As a rule of thumb: the smaller the user story, the lower the complexity and the risk or uncertainty. This idea is also reflected in the modified Fibonacci sequence. In the lower range, the distances between the values are small, which allows smaller gradations in the estimates. In the upper range, on the other hand, only rough estimates can be made, since subtleties are not so important for large and complex User Stories.
Therefore, it makes sense to include only those User Stories in a Sprint that are in the lower range. If, on the other hand, a User Story is rated with, for example, 40 Story Points, this is an indication to the Product Owner that the User Story is too complex and should therefore be split up and then re-evaluated.
One of the advantages of Story Points is that, compared to exact estimates in man-hours, detailed discussions are avoided that would unnecessarily prolong planning. Estimating Story Points by approximating the required effort is faster and sufficient for the purpose of Sprint Planning. In addition, factors such as uncertainty cannot be expressed in hours.
Story Points have another important characteristic: They are comparable within the team but their exact meaning is individual to each team. This means that a user story that was evaluated with two Story Points, for example, should be about twice as complex as a user story with one Story Point. How much effort in hours is actually required at the end varies from team to team. Therefore, it is also said that Story Points are a “relative measure.”
How does a Story Point estimation work in practice?
In practice, “planning poker” is usually played to determine Story Points for User Stories. In the refinement or Sprint Planning meeting, each member of the development team has a deck of cards with Story Points printed on them. Each member chooses one of these cards face down, depending on the estimated effort of the user story. Once each team member has chosen a card, all team members reveal their cards at the same time and can immediately see and discuss any similarities or differences in their assessments. The team then agrees on a Story Point value and continues with the next User Story.
Since Story Points are a relative measure, it can be helpful, especially at the beginning of a round of planning poker, to use a few previously estimated User Stories (e. g. from the last Sprint) as a comparison.
But how to start if there are no references to compare, e. g. in a new project or if no Story Points have been used so far? An easy way to get started is as follows: Select a well-written user story that your team considers to be implementable and assign it a value from the lower end of the Story Point scale, e. g. a three or a five. We have already seen that in the lower range of the Fibonacci scale, smaller gradations and thus more accurate estimates are possible and low values represent less uncertainty. Such User Stories are good candidates for the next Sprint. Experience has shown that teams quickly develop a feeling for how User Stories should be assessed. Therefore, even if it may seem unfamiliar at the beginning, just try it out and you will see how your team develops a common understanding for estimation after a short time.
We hope this post will help you to plan your Sprints better and more efficiently with the help of Story Points.
References
Mike Cohn. Agile Estimating and Planning. Upper Saddle River, NJ, USA: Prentice Hall, Nov. 2005.
Stephanie Porschen-Hueck, Marc Jungtäubl, Margit Weihrich. Agilität?: Herausforderungen neuer Konzepte der Selbstorganisation. Rainer Hampp Verlag: Apr. 2020.