Story points, everybody’s favorite scrum activity. I understand they are meant to be used to help size stories. What usually happens is they are used to determine a team’s velocity.



A sprint goal suddenly becomes lets get 20 story points done this sprint, not let’s deliver stories that have business value.



Also what happens to unknown work that ends up needing to be done, but wasn’t pointed? Well it still has to be done, but if you are judging a team on only story points, then they won’t get any credit for it. So maybe the team failed the sprint goal as they only got 10 points done, but in reality 10 stories only 2 of which had been pointed. Those 8 stories were totally unexpected work, we all know that happens from time to time.



So the standard system seems to be, backlog grooming in which planning poker happens, and stories all get sized by a guess.

A sprint is then planned on how many story points we can do. Where this falls apart is it is nearly impossible to guess how long a story will take from just reading some acceptance criteria.



So what’s my solution? Well in the past I have talked about specification by example as a means to split stories, but where does this fit in a Scrum world?

Well how about in your backlog grooming sessions, instead of just reading the acceptance criteria and voting, use examples.

By using examples here, we can usually see how big or small a story is, the idea being to get a story done in close to a week. So the rule of thumb is usually 4 or 5 examples per story.

Maybe you get a story that has 10 examples, well we can split it here. Now we have two stories in the backlog ready to go. If for some reason some managers still need story points, grand we can just make sure all stories are roughly the same size. If each story has roughly 4 examples then pick your favorite number, 3 for example. All stories are then 3 or smaller.

The idea being to focus on delivering the value of story and not wasting time trying to guess points. Adding up the amount of time spent guessing these numbers will show you how much time we are wasting on this exercise. It reminded me of this Dilbert cartoon.

Eventually your team will get really really good at sizing stories using examples and since all the stories are 3 points anyway, points will fall away.



In a previous blog I talked about the three amigos and discuss and distill. This is basically moving the discuss part of the 3 amigos into backlog grooming to help split stories. You can still keep the 3 amigos lanes on your board, as we can still use the examples as test cases, and here we can double check and make sure everyone understands everything before starting work.

OK you might ask me, well how do I measure my team’s velocity? Well you can measure the cycle time to done.

Say a new feature has 10 stories in it, and these ten stories have been groomed using specification by example. We can then say that each story should roughly take a week. Then the feature will be ready to go in roughly 10 weeks.



By getting better at our story sizing (which happens with practice) we can become predictable instead of trying to guess how long something will take.



Give it a go and let me know how you get on.

