Agile Concepts: Estimating and Planning Poker
Most Agile frameworks include some form of estimation*. Estimating the relative size of stories in terms of effort/time can help a team to decide how many of the highest priority stories from the product backlog can be taken on in a single sprint.
Estimating is also used to measure the velocity of a team (the amount of work it gets through per sprint), helping the business to forecast and budget product development.
Estimating using story points
The most common way of estimating the size of user stories in Scrum is by allocating story points. Story points are just numbers drawn from a pool of numbers of a set size e.g. a story could have 1, 2, 3, 5, 8, 13, 20, 40 or 100 story points.
The reason for using a Fibonacci-like sequence of numbers is to encourage stories to be estimated relatively (e.g. that story looks like it requires about twice the effort for a story we’ve already agreed is a 2 so it’s probably a 5) and to emphasise that the larger the story, the more uncertain the estimate.
A Scrum team will estimate story points during backlog refinement or perhaps as part of a dedicated session. It’s essential that the whole team is involved in the process of estimation so that the estimates are made by the people who will actually be doing the work and are therefore as accurate as possible.
When a story is ready for estimation – i.e. when it is small enough to fit within a single sprint and when the acceptance criteria have been agreed by the scrum team – the team then discusses its relative size and reaches consensus over how many story points of effort it requires.
Stories may be estimated before these criteria are met but should be revisited.
The most common way to do this is Scrum is by playing planning poker.
In planning poker each member of the team gets a set of playing cards with the allowable story points printed on the front as well as extra cards for don’t know (?), infinity or, sometimes, to indicate it’s time for a coffee break.
Once the story is ready to be estimated, there is a round of voting. At the same time, all team members hold up the card which corresponds to their estimate.
If all the team members agree then the story is given that number of points and the team moves on.
If there are discrepancies then the ScrumMaster facilitates a discussion where team members can further explore what’s required, investigate acceptance criteria further etc. There is then another round of voting and this repeats until consensus is achieved.
It’s particularly important to discuss the lowest and highest estimates from the team, this often leads to clarifications with the Product Owner and an updated set of assumptions for the estimate (which should be captured).
*Estimating is a hot button topic in Agile right now. Some argue that estimating is a process of the kind that Agile should be pushing to the background in favour of individuals and interactions and also a form of contracting which should be de-emphasised in favour of customer collaboration. They argue that estimating how long it will take to deliver a product – the development of which will be inherently unpredictable – based on guesswork is a useless activity which fits the incremental model better than it fits a purely iterative one (see Agile vs Waterfall).
The reality is in real world scenarios it is almost always critically important to have ability to forward plan. Story points and velocity give a pragmatic way to do this and often on the projects where Scrum is used there is a good understanding of the type of work being done and the estimates are of a good standard.
Using techniques like triangulation and reference stories aid the process.
Whether you think it’s a futile box-ticking exercise or a useful way for businesses to plan product development, it’s important as practitioners that we understand how to estimate effectively.