Story Points & Fibonacci’s Numbers
Ziegert Group Tech’s Agile Coach Adam Shingleton takes a deep dive into the mathematical, philosophical and sometimes confusing world of estimations.
How long is a piece of string? Or to rephrase perhaps the most dreaded question a development team can hear — how long will it take?
Like many other professions, software development is a tricky, complicated job, and progress can be affected by a myriad of influences and incidents.
If your task is to build a small piece of furniture from IKEA, it’s quite likely that you will need around one hour and a severe headache to complete your task. However, if you need to assemble an entire bedroom consisting of 18 different types of furniture, your estimate might now require a lot of buffer either side of say, somewhere between 1 and 3 days?
Will you become more efficient at assembly throughout the process, or will the lessons that you have learned not apply? Will your brain and body speed up or slow down? Before you begin, should your estimate include the obvious inevitability that some screws will be missing?
In the world of Scrum, we generally use Story Point estimations instead of hours or days. Here’s why…
Just like assembling furniture for the first time, developers are always creating features that they have never made before. Simple features or tasks (like a chair) are generally very easy to estimate in minutes or hours, but estimating very complex and intricate features (like an entire bedroom) for the first time using minutes or hours becomes essentially useless when totalling up a group of estimations.
Planning Poker
Story points are a unique way of estimating the complexity and effort needed to complete a task (we like to refer to complex tasks as User Stories, hence Story Points). During the Backlog Refinement ceremony, each team member will hold a small deck of cards called Planning Poker cards. Each card has a Fibonacci Number on it — 1, 2, 3, 5, 8, 13, 21. When it’s time to provide an estimate for each Story, the Team Lead will ask the team to collectively hold up the card that they think best represents the complexity level for that story — higher numbers represent higher complexity.
On day 1 of following this process, these numbers are almost completely meaningless — they are merely numbers. However, over time (usually 2 or 3 sprints later) a very interesting thing begins to happen — the team begin to accurately associate time, complexity and effort to stories by using these Fibonacci numbers. Our poker players will begin to say things like:
“We agree that its a 3 because we know it’s a fairly easy challenge but will require collaboration in the later stage”
or
“It’s an 8 because we know we’re dependent on X and Y, and this section here will require quite a few days of difficult, manual effort”.
Speed equals Distance over Time
After the first three or so sprints, by comparing the different grand totals of story points for each sprint, you can start making capacity adjustments. The collection of these story points totals per sprint is called Velocity. Velocity is used to measure the capacity and performance of a Scrum team over time. The more sprints that pass by, the more accurate the velocity is as an indicator of a teams performance and capacity.
This is because those Fibonacci numbers begin to hold value — a value that allows accurate estimation of intangible, obscure, complex increments of work. And because of this, you can begin to measure if the velocity of the team is decreasing or increasing over time.
Story points, Velocity, Planning Poker — these are not practical concepts for estimating the building of an IKEA chair. But if you find yourself in a business opportunity that involves the assembly of a new type of IKEA bedroom every week, then you may wish to consider using Mr Fibonacci’s Magnum Opus….
