Poker Planning on T-Shirt-Sizes

22. February 2011

poker

Many of you have definitely heard about Poker Planning. If not, let me quickly recap the idea: The intent is to estimate sizes of user stories but with the special perspective of the team, not the individual. Given “the cone of uncertainty” project management tells us not to invest to much work in too fine granular estimation. So what is the intent and how does it work:

(short notice: for those who know poker planning in and out, jump to “Coming back…” at the end right away)

Intent

* The complete team should estimate to build an estimation of the user stories for the team and not the individual
* Each and everyone of the whole team should learn about all stories to get a comprehensive view on the project
* The team establishes a unit for the size (mostly points) during estimation with which a velocity can be measured for the sprint (V = Points / Sprint)

Way to go:

1 The team comes together
2 The Product owner tells the story to be estimated
3 The story is quickly(!) discussed
4 Every participant draws his/her poker card (on the card you’ll find a number)
5 Chances are high that not all drew the same number
6 Only the one with the highest and lowest vote get a short moment to discuss about their votes
7 A new round of voting happens and reality shows that the votes of the whole team converges very quickly.
8 Continue with 2) only as long as the team is not getting tired…
9 So that’s it.

The outcome is a pile of user stories that is understood and estimated by the whole team. As you know stories are taken from the product backlog and put into the sprint but how many stories do we take? Let’s step back a bit. As any story has a number of points at the end of the sprint we just count the points of all stories that team has finished under its definition of done. This is what we call the velocity. Let’s say the team produced 40 points. Taken the fact the team does not change, for the next sprint we just take so many stories from the backlog until their story points add up to 40, the teams velocity. Sprint planning becomes a piece of cake (as long as the backlog is prioritized).

So, where’s the catch?

Remember the title at the very beginning? The question is about what unit we chose and how we scale it:

Unit:

The unit should be as neutral as possible. Why? It should NOT count hrs, days etc. but a neutral unit that represents a SIZE of a story and NOT how long it takes. But how do you measure the “size” of a story? Only by personally comparing it to the next one. This is not rocket science. It is personel estimation which is becoming a team estimation through the poker game. Duration is always very personal, size is not. The recommendation is to use POINTS which are completely neutral but more important it is possible to add them up. Only if it is possible to add units up, you can get a velocity which is required for the planning and the team to know its velocity.

What’s the point?

Scaling the units: A story of a size of 2 points is twice as big as a story of 1 point. 5 points is five times the size of a one point story. 100 points is 50 times the size of a 2 point story. What about 101 or 102 story points? Are the 101 or 102 times the size? Mathematically, yes, in reality I doubt it. Humans tend to run out of accuracy when they come to big numbers. The higher the number the more inaccurate is the estimation. If you would allow to estimate at 101 or 102 points it would only PRETEND higher accuracy which is not. Therefore people have come up with a scale that has a higher distance between adjacent numbers the bigger the numbers get. Therefore they typically use the following sequence

1 – 2 – 3 – 5 – 8- 13 – 20 – 40 – 100

This sequence looks very similar to the famous Fibonacci Sequence. A number is the sum of its last two predecessors making the distance always become bigger and bigger. Our sequence differs slightly in that it doesn’t start with two ones (1 – 1 – 2 – …) because we do not need the number 1 twice and also we start rounding with the number 20 which normally would be 21. Like I said above even 21 would pretend a certain accuracy that isn’ really there.

Coming back to the T-Shirt-Size…

Now, I’ve seen some teams over the year who used a different way of setting up their scale on Poker Cards – they use T-Shirt-sizes like

XS – S – M -L – XL – 2XL

I found out that typically the team chose that sequence because it felt(!) for them easier or more natural to grasp the size (remember it is T-Shirt-sizes) but how do you actually compare the sizes of the stories? To me (and probably most of us out there) it becomes even harder to compare the story by that. How much bigger is a XS-story compared to an XL-one? What is the actual scale of that story (linear / non-linear)? What lies even deeper is the fact that you cannot sum up: What is the size of the sprint 2xXS + 1xM + 3xXL? And even worse: What is finally the velocity of the team of the sprint and on average over the last three sprints to plan the new sprint? The velocity is important to know. Finally Scrum is also about efficiency and therefore team needs to know how fast and efficient it is!

Recommendation: Don’t go for it

Try T-Shirt-sizes out if you want because you are the team and feel free to try what you may make you more efficient. But I highly recommend not to go for that because you are losing to many options and chances that come from using story points on a non-linear scale.

the above image represents a set of poker cards that a colleague has designed for my team

Trackback URI | Kommentare als RSS

Write a comment