Webinar
Estimation is one of fundamental differences between Agile and other project management frameworks. Namely that given the nature of the work—which isn’t built around hourly billing—it’s much harder to do!
But one solution that works for a huge number of Agile teams is the use of story points.
In Agile, we don’t like to predict how long tasks will take to complete. As you now know, we prefer to work in terms of tasks completed and value generated, not hours worked. Story points are an estimate of how much effort it will take to complete a task.
Effort is approximated by considering 3 factors:
Combining these factors and assigning story points is the job of the team member, not the product owner. Once again we can draw a significant contrast to traditional project management. Because team members are the ones completing the task or user story, they are the only ones qualified to say how risky, complex or repetitive the task is relative to their skills & experience.
In traditional projects, time estimates are almost exclusively the domain of the manager.
Story points are typically assigned using either the Fibonacci sequence, or a slightly “normalized” version of the sequence:
This second option allows team members to assign an absolute minimum effort (1 story point) and an absolute maximum (100 story points).
The ability to accurately assign story points improves iteratively, over time. The more experience team members have with assigning effort and reflecting on the success of past iterations, the better they become at estimation.
Base stories
The simplest way to start with story points is to assign a “baseline” from a previous iteration. Pick one completed user story and, within the team, assign its story points. Some teams will choose two base stories so they can “triangulate” more effectively.
If your base story is an 8, then you should be able to predict on which side of 8 your new story will fall. If you have two base stories, you can be even more specific. Over time, team members can refine their base stories and, with experience, make much more reliable estimates.
Planning poker
This is a more time-consuming and integrated approach, but it’s also extremely reliable for teams using the Fibonnaci numbering method. Here’s how it works:
Gather all team members together and provide each with a set of “cards”, one for each of the Fibonacci numbers. Share the first user story with the group and ask each member to raise the card showing the number of story points they would assign.
If there are disagreements (and there will be!) the team should discuss it proactively, using their expertise and unique perspectives to justify their numbers. The team must eventually settle on a number. This is repeated for all user stories.
While time-consuming, this practice is employed by a huge number of Agile teams because it combines diverse perspectives and gives the best chance of accurate estimation.
ADDITIONAL LINKS
Specificity
The main strength of story points is their granularity. Many other estimation methods use a 3 or 5-part numbering system for simplicity. While simpler, this leads to significant variance between stories assigned the same “difficulty”.
With story points, there is an (effectively) exponential difficulty curve. This allows teams to accurately categorize tasks and, in the long run, enable more successful projects.
Team cohesion
The regular effort of assigning story points helps bring the team together. It introduces meaningful collaborative discussion (which is fundamental to the success of Agile) and gives each team member a good understanding of the skills & expertise of every other member. This often leads to more secure, balanced and supportive teams.
Identify outliers
Most user stories should be assigned fewer than 20 points. If the effort required is even higher (40 or 100) then your best option is probably to reassess the user story itself. It is probably too complex for a single story, and should be broken up into simpler stories. The use of story points makes identifying oversized user stories—in advance of working on them—much easier.
Self-improvement
Perhaps the biggest strength of story point estimation is that, as long as the team reviews past iterations and takes their assignment seriously, estimations will inevitably improve over time. This means the project becomes more successful as it progresses. This is in contrast to most traditional projects where poor time estimates compound, putting team members under increasing pressure and stress over the lifetime of a project.
Promote value
By eliminating the focus on time and replacing it with difficulty, team members are never forced to rush or deliver partially-complete work. This enforces the culture of value creation that is at the heart of the Agile method.
While story points are probably the most popular, there are various other techniques which are used for estimation in Agile projects.
This is a moderately scientific approach that uses the expertise and perspectives of team members to reach a reliable estimate. For each story, the team must estimate the effort for 3 hypothetical cases:
The estimate value is then calculated as follows:
Estimate = (O + P + 4M)/6
This number considers both the extreme positive and negative outcomes but gives greater weight to the most probable scenario. While it can also be calculated giving equal weight to each case, the equation above should be more reliable.
This is perhaps the simplest of all estimation methods. Teams assign every story to Small, Medium or Large difficulty. The shortest and least complex stories go to “small”, while the longest and most complex fall under “large”.
Some teams extend this method to include “extra small” and “extra large” sizes.
Teams put one story in the middle of a continuum. They select the next user story and agree whether it’s more or less effort than the 1st. It is placed accordingly. The team continues this approach for all stories until they have a spread of tasks, arranged by relative (not absolute) difficulty.
Another method that is very similar to relative sizing is affinity mapping.
For large numbers of user stories (for example, 50 or 100+) methods like t-shirt sizing lose some perspective, while planning poker becomes extremely mundane. Bucket estimation is a suitable solution.
Put “buckets” on the floor (or on a screen) which represent each of the Fibonacci numbers. Then give the team a card with the first user story. Allow a very brief discussion before putting it in an agreed box; repeat this process for each story.
Bucket estimation should be rapid-fire and there’s no editing or re-organizing. Despite its speed, this will effectively and accurately sort the majority of user stories, bringing a net positive impact to the team.
We’d be happy to provide a bespoke 1:1 demo on how Cloud Coach can benefit for your business.
