Andy Hawthorne

Thoughts, stories and ideas

Estimation and Story Points in an Agile Project

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 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:

  • 0
  • 1/2
  • 1
  • 2
  • 3
  • 5
  • 8
  • 13
  • 20
  • 40
  • 100
  • Infinity
  • 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 to calculate a time block for it.

Reaching agreement

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. 

Final thoughts…

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.

Next Post

Previous Post

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

© 2020 Andy Hawthorne

Theme by Anders Norén