Scrum tells us that it doesn’t matter what a story point is, only that it exists in some way. Try explaining that to your stakeholders and see how long you last 🙂
Every stakeholder and product owner wants to know two things… “How much will it cost?” and “How long will it take..?” and no amount of wriggling will get you off the hook.
So for this you need to know a couple of things:
Total # of Story Points
How big is a story point? And how do I know what the velocity is?
Think about something non technical, like digging dirt out of the garden…It’s an example that has been used time and time again I’m not sure who came up with it first but it works so well
If I was to move 100 kg of dirt at 10 kg per hour it would take me 10 hours.
So that would equate to:
100 Story Points (100kg of dirt) / 10 Story Points per Sprint (Moving 10kg per hour) = 10 Sprints.
Therefore if we want to answer how long will it take to develop a particular software product, we:
Add up the story points, divide by the velocity, and that gives us the time.
In order to do this we will need to create a reference story for all of the other story points to be compared against. So how do we establish our reference story? And how do we know what velocity is?
In a Scrum environment, estimates are supposed to be done by the whole team, those who will actually perform the work. So the team defines what a story point is.
The suggested way of doing this is to consider the task list and state that the task that appears to be the easiest to perform is valued as 2. All other tasks are estimated relative to this task. However it doesn’t have to be the smallest task, just a task the whole team can agree too.
So what do you use? The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.), t-shirt sizes (XS, S, M, L, XL, XXL, XXXL) or anything that starts small and ends up large. The most important thing here is that the team understands and responds to the values that are being used.
Ok now onto Velocity. What is it? Where does it come from? Here is another answer that the powers that be won’t like…In the first sprint, we guess. It’s all about gut feeling, after a few sprints things will become clearer.
After each sprint the velocity is measured, after one or two sprints we have an average that we can use for predicting sprints in the future. From this we can estimate the completion date. With a little bit of thinking we can calculate values such as £/Story Points which can be used to estimate project costs.
The important word here is estimate! It’s not definitive or fixed.
It is worth remembering that Story points can create a lot of vagueness within the agile process. For every team, story size could mean different things depending on what baseline they chose, so you can’t cross estimate teams. If two teams are given the same stories one team can say their velocity is 35 and the other 12 dependant on what numbers they choose.
If you use Story points in this way the Scrum Release Burn Down Chart can provide a fairly accurate picture of the progress of the project, and this will give the management a good overview of the projects progress, or lack of progress.