Story Points should not be numbers.
Earlier I introduced the concept of Planning Poker for estimation. (Part One. Part Two.) This has continued to be a very good tool for our team, and specifically our project manager. While most notably used for estimation, that is only part of the benefit that is received by using a process similar to Planning Poker. To our team the interaction between the team and the product owner coupled with the team wide understanding of upcoming user stories are bigger benefits.
When I first introduced this new form of estimation to the group I made a mistake. I did explain the concept of story points to the group and even had cards made to represent them. The cards all had graphics backing the central number to help frame them as relative effort. Boxes play heavily into the product we develop, so I had single boxes, groups of boxes, and pallets of boxes for the story points. I also created a separate set of cards for estimating tasks and bugs. They were to be done in hours, so they had cards with numbers and no background. The mistake is that the story points were set up with the same set of values as the hours.
What we found in our first couple of estimation meetings is that having story points as hours was hard for a team new to estimating requirements with story points. This came as a surprise to me. We are all intelligent people on the team and deal with the advanced concepts that arise in writing scalable enterprise level applications from the ground up regularly. Surely something as simple as a mind shift from hours to effort points when moving from tasks to story points would be easy enough. It wasn’t.
We gave it two estimation meetings and had the same problem in both. As soon as people thought about the numbers after discussing the user story it was a matter of how many days they thought it would take them. They were using the story point cards to estimate ideal days of their own effort.
Speaking with the team it became clear that we would be able to start taking each others needs into account during these meetings, but the change from ideal days to vanilla points was going to be another story. It was time to find a solution.
I had read about people using objects for story points, and in fact I had tried to do this. Our story points were introduced as boxes. 1 box, 2 boxes, 13 boxes. The cards showed numbers on them with watermark style pictures of these boxes. It didn’t matter. People focused on the number 13, not the picture of a pallet of boxes. For our team this wasn’t enough. The project manager and I did some research and between us we found and came up with a solution to help the team while still allowing us to use numeric story points for reporting purposes. We created a set of t-shirt sizes.
The idea of the T-Shirt size was simple, just as the idea of the story point. Story points are largely about relative sizing and the number itself is really inconsequential. We simply replaced the numbers of boxes with sizes. XS, S, M, L, XL, XXL for 1, 3, 5, 8, 13, 20. We took this concept and handed the team cards of S, M, and L to start. Based on the discussion we noted whether it was really a S or an XS. We did not share the conversion of these sizes to numbers with the team. It’s not that we hid it, we just didn’t make a point of what the conversions were.
The payoff was immediate and big. Not one person on the team had any problem using these sizes and ignoring the idea of how many days they thought it would take them to finish “their part” of a user story. We were able to convert the sizes to points after the estimation meeting with little effort and fill in as if we used the original cards. The value for the project manager and product owners was restored by providing a good estimate of total effort. The value to the team was raised as estimation became even more about what the whole team needed to accomplish to complete a story.
The only change we have made to this new process since has been to add in the middle sizes. the team now gets to use XS, S, M, L, XL to estimate. We also provide a zero and an infinity. Finally, we have been able to take some of the better defined and simple user stories and translate our planning poker estimation to email estimation. The details of that will be covered in a future post.
How do you define value in your estimation meetings? What have you done to achieve greater value from them?
