I get around the problem of the meaning of the units shifting from session to session the same way. Start an estimating session with, “OK, here are some examples from past sessions…” and then read a few random items being sure to cover a variety of sizes.

Glad to have stumbled across your blog. I’ve attended a couple of your tutorials over the past 18 months and become a big fan as a result.

On the topic of Planning Poker, I’ve noticed a few patterns in the time that we’ve been using it, and thought I’d pass them along for discussion or consideration.

In your example where you say that one person believes an item to be 8 but goes along with 13 because it’s “close enough”, I’ve found that I have to be sure to explain what that means to avoid a particularly nefarious result. What can happen is that the person who thinks it’s an 8 but “goes along” with the 13 is still regarding that item as a 13 in their head. So when another item is being discussed, he or she is now sizing it as an 8 (say) because it seems about half the size of the previous item (which was a 13 as far as they’re concerned), whereas everyone else is considering it a 3 or a 5, for exactly the same reason (half of an 8)! In other words, that person said “close enough” but didn’t really give up on their own answer… they just “went along to get along!” Because of this, I’ve had to say things like, “OK gang, so we all agree that that last item was an 8. That means that no one should still be thinking of it as a 5, or as a 13, or as anything other than an 8. Agreed?”

Another pattern seems to manifest itself when teams size things in bunches but never take the time to compare those Story Points to anything outside of that new group of items. Sure, they’ll have a fairly consistent notion of what a 1 is, perhaps, but won’t actually look at each new item, after sizing it, and ask, “Is this really about the same size as _____ from the backlog?” where that other item was sized at some earlier date. They end up with little pockets of backlog items that are sized reasonably well compared to each other but which actually represent slightly different units. You can imagine what a release plan built on those non-aligned backlog item sizes looks like, where the velocity never achieves anything resembling consistency.

Not sure if these are common patterns or not, but thought I’d share them regardless. Always happy to find people willing to “talk Agile!”

1 2 3 5 8 13
1 2 4 8 16 32

The top number is how many points estimated for a package of bugs on line 2. In other words, on avareage, 8 defects is worth 5 points. 16 defects is estimated as 8 points, and so on.

Is this real? Well, I noticed the pattern, I didn’t impose it. Cool, eh?

I can’t recall hearing a team call their bug list a “defect backlog”. The normal mode is that bugs go into a defect tracking system (because this system has become a workflow tool between the development group and other groups such as support). One common approach is to grab anywhere from say 2-12 bugs that the product owner wants fixed, estimate them in story points (or ideal days if the product backlog is estimated in those instead) and then include them as normal in sprint planning. So, yes it’s common to estimate defects but usually in clumps rather than individually. The other approach if you have a lot of them is just to make an average fix-time estimate per defect.

Many thanks.