Can one size fit all?

[cthompson2]

By Christine Thompson

A member of one of my Scrum teams recently pointed out that we only tend to use a limited range of numbers on our planning poker cards. Most of our stories get sized in the 3 / 5 / 8 range and he questioned why we weren’t using the full range of sizes for our stories. Here is my take on the situation.

Here is our sprint, that we need to populate with user stories:



Within the Scrum team in question, the stories being written for the work we need to complete are currently being pitched very well. They are small enough to be clear what needs doing but not so small that they’re too granular. Within the team, we’re starting to write stories that are generally of a similar size. This suggests that we’re breaking them down correctly, to a consistent and appropriate level. Our sprints look like this, populated with a number of uniformly sized stories:



The alternative would be to aim for stories within a not too narrow range – maybe 1 to 13 points. This allows you to populate a sprint with small, medium and large tasks. This is a good approach for the circumstances where you need to include a ‘large’ story, so the sprint must also contain ‘small’ stories too, to fill the gaps:



The one thing we want to avoid is populating a sprint with one, big story. Just bringing in one or two large stories carries a lot of risk, as in the last example below. If that story gets blocked, the whole sprint grinds to a halt:



So what are the benefits of sizing stories consistently? There was one occasion recently when we sized something at 13 points. The Lead Developer took it away and broke it down because it was considered too big to be properly understood. This shows that we’re trying for consistency and the sizing highlights when we have not achieved it. Anything above 8 points may be too large and complex to be sized accurately. Breaking it down ensures that the story is well understood at the appropriate level.

The important thing to note here is that we're not limiting our choice of story points to a fixed set but instead we're writing our user stories to a defined size.

Let me give you a couple of examples from another team. When a new PO joined the team, he was writing stories at a very granular level. The teams were giving them 0.5 or 1 point and asking him to combine them to make them bigger, as they felt too small to be worked on individually. Conversely, when he asked for a big, vague story about a database-driven feedback system, the team sized it at 100 points, showing it would need to be very well specified and broken down for us even to attempt to work on it. Here our use of the extreme planning poker cards showed a problem that needed addressing.

The exercise of sizing confirms we have pitched the story correctly and warns us when that is not the case so that action can be taken. It's unlikely that user stories are always going to be sized equally, and you would start to wonder whether the team were even thinking properly about them if they were. However, the correct preparation of stories for sizing, and the discussions to confirm our understanding of them, give us the best possible indicator that we understand the work we're doing and can successfully achieve the sprint.