Every new team I have ever began with on their Scrum Journey has asked,
What is a Story Point and how do I estimate them?
Now what I’m going to say in this post will probably get me mashed by the Scrum and Agile world police, however, why dwell on explaining Story Points for hours, days and even weeks. The problem is that most people are converting over from a waterfall or Project management type organization. There they were always asked for estimates in hours. Let’s face it many “agile” organizations still want hour estimates for tasks. Personally, I hate hour estimates and this comes from a guy who did project management for 20 plus years.
I laughed when an “Agile manager” said they would back into hours based on the story points. I wanted to say and you have a problem with me letting the team come up with some rough hours to story point estimates. A classic Dilbert cartoon. Anyway, I would argue that after about the 2nd or 3rd Sprint the teams don’t think in hours any more, except when an “agile accountant” (my term) asks them for hour estimates on tasks. Someone in the organization always has to try and figure out hours. They just can’t help themselves,
So any way within minutes a Scrum Master can get past the initial mental blocker of what a story point is. And we can even use relative sizing in the first Sprint. Soon the team will not even ask about hours.
Typically Story Points are assign with the following point sequence, from lowest to largest. The lowest being the smallest and probably an easy story to complete
1, 2, 3, 5, 8, 13, 20, 40, 100 or you can use the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 21, 34, etc…
either way there is no 4, 6, 7, 9, 10, etc…
What is nice about this is that in the end it makes it easier to just to do relative sizing than to directly relate points to hours, which is the ultimate goal or getting away from estimating hours because we all know it will be wrong anyway.
Hear are some initial sizing rules some of my teams have used:
- <1day (~8 hrs) – > 1 pt
- 2 days (~8 to 26 hrs) – > 2 pts
- 3 days (~26 to 32 hrs) – > 3 pts
- 5 days (~32 to 40 hrs) – > 5 pts
Another team used:
- 1 pt. – 1 Day ~ 6 hours or less
- 2 pts. – 2 Days ~ 12 hours or less
- 3 pts. – 3 Days ~ 18 hours or less
- 5 pts. – 4 Days ~ 30 hours or less
- 8 pts.- 5 Days (week) ~ 48 hours or less
- 13 pts.- 10 Days (2 weeks) ~ 78 hours or less
- 20 pts. – 15 Days (3 weeks) ~ 120 hours or less
- 40 pts. – 40 Days (6 weeks) ~ 240 hours or less
Plus I would always have them throw in another twist in their estimating, where the Team feels appropriate:
- Add extra points – Add a point for complexity
- Remove extra points – Remove a point if the story is straight forward and simple
As the team got passed the first couple of stories, I would have them apply relative sizing. The biggest hurdle is getting the team to be OK with being Wrong. No matter what you do they never want to be wrong. But they will be. As a Scrum Master we just have to help them get past that idea of being wrong and that is OK.
- Compare Sizing to other Previously Completed or Estimated Stories
- Advice: Do Not Overthink – Teams get better as Sprints Progress
- Some Activities just are copy and paste from previous Sprints. Here the tasks are the same but the desired outcome might be different. I wonder how many people are going to pick up on the duplicate in the relative sizing graphic above?
Like I said earlier, this may not be the most “correct” way of getting teams estimating stories, but it is a quick and dirty way of getting the teams onto other activities.
