Estimation and Story Points in an Agile Project
Reading time: 3 minute(s) - 500 words
Estimation for coding work is hard. And developers are rubbish at it. So, there has to be a better way and there is. Enter story points…
In any project there has to be a plan. And a big part of that plan is deciding on what needs to get done - and in what order.
In an agile project, user stories are the initial point of contact with the requirements.
We break those user stories into tasks to go in the backlog. From there, the tasks will likely be part of a sprint. And that means we need to know how long the task will take.
There is also the quote. Digital agencies (for example) will quote the work based on how long developers say it will take.
Learn from experience
One of the best ways to get estimation right is to use past experience. If you know that task x is like new task a, then you know how long new task a should take.
It’s worth keeping a log of reference stories for this reason. That way, the first task in estimation is to check the log for anything similar.
Breaking it down
One user-story gets assigned points based on it’s perceived complexity.
You can use the Fibonacci sequence for this. The idea being, the higher the number assigned the more complex the story will be to complete.
There is an alteration in the sequence for agile purposes. It looks like this:
- I need to lay down (?)
- Get me coffee
The explanation being:
0 - task is already done
1⁄2 - tiny task
1, 2, 3 - small task
5,8 13 - Medium-size task
20, 40 - huge task
100 - massive task
infinity - well, shit
? - No idea, can’t work it out
Coffee - When all else fails…
The important thing about story points is: they are specific to development work. They don’t include all the usual stuff we do (answering emails etc.).
By assigning story points, the team can decide on the complexity for each piece of work. It’s better than trying calculate a time block for it.
The idea behind agile planning poker is: everyone must agree how complex a piece of work is.
In scrum teams, it’s the team that decides how long a task will take. The scrum master and stakeholders don’t decide.
This often causes problems and needs careful adaptation. There is a business case for doing the planned work, after all. And it has to be viable.
That’s why account managers in an agency shouldn’t quote without a planning meeting.
Get rid of finger-in-the-air estimation and you’ll reduce the nasty surprises that occur.
It does take some effort but it is worth it. Because in the end, it’s about getting jobs out of the door and getting paid.