“On “Pointing” Stories” from on Old Blog
Many years ago, I had a blog where I commented on a number of things related to software process largely with an agile-related slant. I got directed to that blog a couple days ago and I thought I might present them here and see what people think. I have not updated them in any serious fashion because I am happy to have them criticized in the light of current thinking.
So, from August of 2009 here is the seventh:
One of the, if not “the,” most common way for agile teams to estimate work for an iteration is what is known as “Planning Poker.” Perhaps the best explanation for this approach is to be found in Mike Cohn’s book, Agile Estimation and Planning.
My experience when watching teams try this the first few times is that they have a hard time going from story to story, estimating the point value of each story. I think this is because each story is treated somewhat in isolation from the others. Even if a team considers, say, the top 10 stories in priority from the Product Backlog and has that set as a focus, it seems hard for them to feel they understand what they are doing in assigning points to a story.
The idea, of course, is that points represent a relative relationship between stories, not some absolute value that connects with some other, more familiar, value. Sometimes, the suggestion is made that 1-point represents 1 “ideal day” of effort. That is it means ~1 person/day of effort. This can be helpful because it isn’t too detailed, but does give a team some reference to something they can relate to.
At Agile Roots this past June in Salt Lake City, I heard a “lightning talk” by Chris Sims that made a lot of sense on this topic. Actually, what he suggested is a very simple, classic technique for ordering things without trying to be numeric at all, at the outset. Very simply, he suggested just ordering the stories using a simply “insertion sort” approach:
1. Pick all the stories you want to deal with for the estimation session (as it could be iteration planning or planning for an entire release, i.e., looking at the whole Backlog, not just a few highest priority ones).
2. Take any 2 stories and decide which the team thinks is larger (or smaller) than the other in effort, but don’t try to assign any specific “quantity” to this.
3. Take 1 more story and decide where it fits relative to the 2 you already now have ordered. It’ll be smaller than both of them, larger than both of them, or fit in between the two of them.)
4. Now, just repeat the last step for every remaining story, fitting each story, in turn, into the ordering that exists. (Don’t spend too much time worrying about whether a given story is, perhaps, equal to one(s) already out there. Just drop it into the ordering close to where it seems to fit.)
5. When you’ve done this with all the stories, you’ll have a complete ordering of the stories, relative to one another, from smallest to largest (in terms of effort ), but will not have had to worry about exactly how “big” any story is.
Now you can start the process of assigning points to the stories:
6. Look at the lowest ranked story and decide if it is so small you want to assign it “0” (it can be done in much less than a day) or whether you want to call it a “1”.
7. Go to the next smallest and decide if that one’s about the same as the prior one (and assign it the same value) or it is larger enough to assign the next number using the scale you have selected. (The reference describes one such scale know as a Fibonnaci series. This scale is suggested since, as stories get larger, the jumps between numbers increase. The idea is that it is not useful to debate aboput 1 pt differences between larger stories since this whole approach is a relative estimation technique, not an absolute one.)
8. Continue doing this with all the stories until you complete the largest one.
9. Now you have a fully pointed set of stories.
The same decisions end up being made, but it’s done in two, perhaps easier to comprehend, steps. The first sorting step may be easier to do than thinking about both the relative ranking and the point value at the same time. With the ranking done, there is an already implied sizing and it is a matter of assigning the points knowing that the values will increase as you go through the ordered set of stories.
This approach does not relieve much of the burden of deciding whether a story is about the same, 2x, 3x, etc. as the last story. But, you can be sure that it is at least the same or larger given that you are now pointing from smallest to largest.
I’ve found this approach to help teams. They can usually do the initial sorting without a lot of concern because it is, truly, a relative relationship activity. Assigning points is still somewhat vague early on in a team’s experience, but the already ordered set of stories helps a good deal rather than randomly picking stories (even in business priority order) and trying to assign points immediately.
Have others used this approach rather than the traditional Planning Poker approach described in the text linked to from above? Do you think this is too much work compared to the typical pointing approach?
[Since I wrote this, I have seen this same approach called Affinity Estimation because it is an application of a quality “tool” known as Affinity Grouping.]
