To estimate how much work to plan you need a unit of measure.
Forget about estimating time – it’s time for story points!
A story point in agile is a unit of measure representing the work that needs to be finished to meet the definition of done. Agile teams use story points in the process of work estimation.
You need to use story points in the estimation process.
No more estimating time. No more counting men-days.
Story points are practical, efficient, and in the long run accurate.
What does a story point look like?
Some say that you can estimate using different sizes of t-shirts like S, M, L, XS, and so on.
Another unit I heard of is animals: pigeons, pigs, elephants, whales… Of course, you can think of any other abstract units.
From my point of view, it makes the whole process a little bit complicated.
A scrum master can use this kind of metaphor in the estimation learning process.
However, the best unit to use in my opinion is a number.
When it comes to managing data – numbers are practical. You can take numbers and use them to make statistics, reports, charts, and any other tools that you can think of in order to use them to work with teams.
And you will need to work with your team on how they perceive a story point and how they estimate tasks with it.
What scale to use for story points?
If it goes for numbers I personally use a modified Fibonacci sequence.
0, 1, 2, 3, 5, 8, 13, simple and quick during planning.
The reason someone uses for example animals is that relative estimation shouldn’t have anything to do with time.
When looking at a number some people can automatically convert 1 story point to a man-day and as I said we don’t want that.
It is an obstacle that a team must overcome when learning how to estimate. It is best to carry out workshops during which the team exercises the estimation process.
When the team implements an abstract way of thinking about work in separation from time then symbols such as animals or buildings are unnecessary.
What is the Story Point for?
As mentioned before it’s a unit of work measure for relative estimation.
The team plans a sprint – the plan is represented by the sprint backlog. It is a pack of tasks estimated in story points. The sum of those points is the sprint load.
We track from sprint to sprint how many story points are assigned to completed tasks. An average from those past story points in each sprint is known as the team’s velocity.
Based on the team’s velocity and some other factors we are able to calculate the next sprint’s capacity so we know how much work we can plan.
You can read about how to calculate capacity here.
How to track velocity?
Velocity is a pretty basic thing to track about the team’s activity.
You can find reports like velocity, burn down, or burn up charts in work tracking tools like JIRA.
Of course, you can also track velocity in excel if you want – then you can add some other things to the report that are not available in your work tracking software.
In conclusion
I strongly recommend for you as a scrum master to work with your team on a proper understanding of the story point and relative estimation.
