Anyone who practices agile methodologies such as scrum is going to be very familiar with the practice of story pointing user stories (also known as poker planning). The good ole’ fashion 4, 8, 13, etc. Fibonacci sequences we assign to user stories of a sprint.
If you’re not familiar, it’s where the team gathers together to discuss the user stories to bring into a coming sprint and assigning each a number called story points. These story points are estimates that represent the level of difficulty and time it is expected to take to complete the story.
The team often will have discussions on whether a story is a particular story point number and argue their point of view until the team comes to an agreement to what story point it should be. I’ve done this type of work estimation for a long time that it’s natural for me… until we did something a bit different on a scrum team that I was a part of.
In this blog, we discuss a different way to assign poker points to user stories that could be beneficial to your scrum team – relative story sizing.
How It Works
Normally during sprint planning, we discuss the stories that we intend to bring into a sprint. Then, after discussing each story, we poker plan them and establish the level of effort we estimate it to have.
But while on a client project a couple of months ago, a new scrum master joined our agile development team. He wasn’t a particular fan of the numbers we were assigning one user story as compared to another.
Cue the next sprint planning session. After we finished discussing the first user story, our scrum master wrote the user story on a sticky note and posted it on the conference room wall. Then we moved on and discussed the second story for that coming sprint.
Our scrum master then asked us if that story (Story #B) was easier or more difficult than the first user story (Story #A). If it was easier, he’d put it to the left of the first user story. If the story was more difficult than the previous story, he’d put it to the right.
As we continue on, we position every new story relative to the ones already on the board based on the estimated level of difficulty. Some of the user stories could go between two that are already on the wall or could even be right below an existing one, indicating they’re about the same level of difficulty.
Basically, we’re literally positioning physical user stories based on their difficulty as compared to each other on a board. After the user stories were done we then assigned story points to them based on the physical position they were in.
For example, the user story to the far left would likely be the easiest of the bunch and we assign a lower story point to that. Then as we move on to the stories to the right, the story point we assign would most likely increase compared to the ones located to the left of that.
In this example, User Story A would be considered the easiest story to complete, while User Story E would be the most difficult to complete. User Story C and User Story D would be considered the same level of effort.
Here’s what it would look like after assigning poker points to the stories:
How It Won Me Over
Like any new agile practice, I was a bit skeptical. Maybe it was because I was so used to throwing up poker point cards for a long time that I saw no benefit in trying a new way to estimate work. However, it dawned on me at the end just how accurate the points were.
When a group of user stories is positioned on a wall from left to right, it was a lot easier to assign story points to them. The numbers actually made sense instead of estimating a story by themselves and assigning a number (almost arbitrarily) to them. This logic in itself won me over.
There is also a low barrier of entry to start using it; relative story sizing is simple to integrate it into your sprint planning sessions. The level of detail you go on the user stories is really about the same as before relative sizing, so there isn’t too much-added effort. Your scrum team can easily get started with just a pen, post-it notes, and an empty wall.
Over time, using this approach has made our agile team’s velocity more consistent. In retrospect, back when we didn’t use relative sizing, our numbers would be all over the place. Consistent, correct story planning helps us ensure we meet the deadlines our team sets.
Conclusion
In conclusion, relative story sizing is a neat variation of poker planning. I found that it helped my scrum team significantly in estimating the poker points of user stories by seeing them laid out and in relative order of effort.
I encourage you to give relative story sizing (or even a variation of it) a try in your scrum team.
