Planning Poker – A Few Thoughts
I read a question posted on the Scrum Alliance Google Group, and jotted down a few thoughts about Planning Card Games.
The Basic Question Being Asked:
How do you describe a 1 to the team for Planning Poker®?
The value of Estimating using Card Games:
To me, the main value of story point estimating is as a tool for a team to learn how to break things down into “Sprint size” pieces. As a team becomes skilled at breaking stories into smaller (yet still valuable and deliverable) pieces, the less need they have for using estimating games. Once the ability to “chip off a small, do-able, deliverable chunk” becomes easy for the team, the work flow changes a bit. The team no longer needs estimating games – they simply choose important stuff, break off a few valuable, small pieces to work on, and then do the work and build/deploy. Over and over again.
Many don’t see it that way, and use estimating games to make decisions about what work to bring into a Sprint. That is a legitimate use in some workplaces, and whatever works for you is the right thing. For me, the scheduling of work for a Sprint is not nearly as important as breaking work into a “do-able” condition, and getting it done. I’m interested in choosing what we work on based on the value to the “customer”, not how big things are. We can only do so much work at a time. Finding valuable things to work on is where I put my focus.
Discovering What Those Numbers Mean To A Team
One approach that has worked for me in finding a way to size things is to do it during the first Sprint Planning Session:
Take all the Stories you are considering, and lay them out in “size order” on the table – No numbers, just “Is this bigger or smaller (or the same) as that”. Once you have them laid out you can group them into the numbering system you use. The group of the small items becomes 1, next group 2, and so on. During the Sprint you will get a feel for if the 2’s were more or less double the 1’s, and so on. “More or less” is fine – you don’t need precision. You are just “getting a feel for it” anyway.
Over time, the team will be able to quickly gauge a basic size for each story – with the main goal being to find the ones that need to be broken down further so they can be taken on as work. Once a story is taken on as work, you’ll discover the real nature of the story and it’s “size” – it is often found that it needs to be broken up into a few smaller chunks.
Still, What is the Answer to “How To Describe a 1 to the Team”
This doesn’t really answer your question: “How do you describe a 1 to the team for Planning Poker®?” – but it replaces it with a way to work with the numbers. In the past when I used story points and planning cards, I found this to be the definition that worked for me: The “1” story point is the smallest thing that we can do discretely that brings value once built and delivered. Smaller than 1 is the place to put things that are tiny, but not really stories. We would mark something as zero if we felt it would “come for free” in the doing of another story. Also, anything bigger than a 5 was put into a bucket of “Too big, must break down before we put any work on it”. For me, usually 1 & 2 are considered for taking on as work, 3 & 5 need to be sliced up if at all possible (and if it can’t be easily sliced up it’s a signal that we need to learn how to better define and break up a story), and 8+ is “Too Big – must be sliced up”.
Note: Planning Poker® is a registered trademark of Mountain Goat Software, LLC.
James Grenning:
Your approach is like the approach I use. I call the activities of laying out all the stories and creating a release plan “The Planning Poker Party”. I stopped using planning poker about a year after its invention as we discovered a better way, affinity grouping. I’d like you comments too. See http://www.renaissancesoftware.net/blog/archives/36
Like you, if a story is not a one or a two, it is too big and needs to be split, lest there is too much risk. I am good with having bigger numbers on some of the stories (usually round numbers like 5, 10, 20, 50…) for budgetary purposes, but they are out a way in the release plan.
8 January 2013, 8:44 pmWoody Z.:
Hey James! Thanks for the comments.
I read your blog post and I am going to leave a comment there. In my current workplace, we don’t estimate at all – or at least we don’t do anything that I call estimating, including “story points” or “relative sizing”. This is possible, in part, because we’ve become pretty good at slicing off small, potentially valuable bits and getting them “done” and delivered. We don’t always do great at that, but that’s okay: a related skill is to recognize when we’ve bitten off more than we can reasonably swallow – and when that happens we simply “spit most of it out” and chew up the bit we CAN reasonably swallow. Then take another bite. [ Hopefully, I can mix a lot more metaphors into this if I keep at it.]
I like the ideas and approaches you describe. The most important factor for me is to have work broken down into very small (yet still usable) bits. The second most important factor for me is I only want to “slice off” stuff we can do “now”. If I break down a big piece into all of it’s smaller pieces there is a good chance I’m wasting time on stuff I might not (or probably won’t) actually do.
Of course, each company/project/environment is different, and “what works here doesn’t necessarily work there” – but I think simplicity and eliminating waste works everywhere. So – maximizing the amount of work not done is great advice. (I don’t have to tell you that!)
Thanks for the Agile Manifesto, by the way!
9 January 2013, 11:32 amRon Jeffries:
It doesn’t matter what a “1” is. There is no point to describing a “1”. The skill is in making stories “small enough”, as you do, as James describes, and as anyone who’s built up any skill surely does.
When you do that, if you want to know “when you’re going to be done”, you can simply count stories per unit time, and project the line.
However, that behavior is shallow Agile. What Agile is really about is being in a position to release what we have Right Now. When we do that, we’re always done, and it’s all about what shall we do next.
9 January 2013, 2:19 pm