The dev team at Clean Coders recently built an app to estimate stories. We use it all the time. You're welcome to use it too! It's free!

"Clean Coders Planning Poker"

Clean Coders Planning PokerĀ®. We're proud of it. Here's why...

Estimating Is Essential, And Hard

Fish gotta swim. Coders gotta estimate. You know how it is. Though coders would love to express their creativity by building castles in the sky (as I often do), deadlines have to be made and costs controlled. The business behind the software needs coders tethered to the ground, with estimates.

It should be obvious that we at Clean Coders practice Agile development so estimating is a weekly event, if not more frequent. I know it's the same for many of you. Add to that all the estimates we do for potential clients and it adds up to a boat load of estimating. Through experience, we've culminated techniques to make estimating as painless as possible and put them into this Poker app. For us it makes quick work of all the estimating we do.

It's a Team Activity

You're not going to let me estimate your work for you, and I certainly won't let you estimate my work for me. We've all been burnt by that before. If we're on a team together, we estimate together.

Everyone Gets a Voice

ANY team member may end up working on a given story. So it's important that EVERY team member owns the estimate. That means that everyone on the team should estimate every story. To save time, don't discuss it right away. Everybody, just dish out your best guess. If the whole team agrees, write it down, we're done.

What if we disagree?

It's bound to happen, and it's a good thing we're estimating at the same time in the same "place" so that we can talk about it. Maybe you point out all the complexities of the story that I'm not seeing. Or maybe I tell you about some code I just wrote that solves most of the problems. Either way, when our estimates are way off we get to hash it out until the whole team is on the same page, and our estimates closer to the truth.

Planning Poker

Estimation meetings are easily and often bogged down by debate and conversation. The less talking, the better. In 2002 James Grenning invented Planning Poker in the spur of the moment to address this. Planning Poker is brilliant! Which is probably why so many teams have adopted it. Here's our a round of Planning Poker plays out.

Not only is Planning Poker efficient, it's also fun to play!

Remote Teams

More and more these days, teams work remotely. The Clean Coders team works remotely and before we built this Poker app, planning poker was a challenge. Here's how it typically played out (hint: it didn't work well):

Clearly this was inefficient. The idea of "no talking" went right out the window. Tadd, who was relatively new to our Agile process, would repeatedly ask "Do you really want customers to sit through this process?" He obviously found it painful.

One day we added a story to build a Planning Poker app to scratch our own itch. It seemed like a fun project, and we were in need of a change of pace. Two weeks later, we were estimating in a room on our brand spanking new Poker app, and just like that, estimating was fun again! Playing Planning Poker as a remote team is not just as good as playing in person, if not better.

Only Fools Give One Estimate

"What is an estimate?" Careful! There are multiple answers.

Countless times has this discrepancy cause pain and suffering to coders and managers alike

Coders know the drill. They've been pinned to an estimate before, working overtime in a death march to finish the job. "Never again!" they'll say to themselves. "Next time I'll pad my estimate to avoid this pain." Thus Conscience Does Make Cowards of Us All, or possibly liars?

Managers are left their own guess work. "Either the coders' estimates are right or wrong. Probably wrong. But how wrong?" They lack information needed to make decisions. More often than not managers are left at the mercy of their coders.

It's doesn't have to be like this.


Clean Coders uses the three-point estimate technique from PERT (Program Evaluation and Review Technique), created back in 1957 by the US Navy's nuclear submarine program. Every estimate has three components:

The output of this technique is not a single number, like 2 weeks or 50 points. No. The output is a normal distribution; a statistical model that conveys confidence and risk.

Check out this example from our Planning Poker app. It's the result of estimates we did for an architectural software project, but that doesn't really matter.

Example Normal Distribution Curve #1

The value of a point is arbitrary. Each team decides what it means. For the sake of argument, let's say that some Tiger Team can complete 2 points per week at a cost of $2,500 per point. Then we'll have the following table:

Example Normal Distribution Table #1

That's exactly what management needs, as we'll explore next.

For coders this is liberating. No longer do they need to worry about padding their estimates. On the contrary, they're motivated to be totally honest and express the full range of possible complexities or unknowns in their estimates.

Stories Need a Single Estimate

Yes. When you get down to the scale of an iteration, stories need a single estimate. With the 3-point estimate PERT offers a formula to calculate the Mean, and that is what we put on the story cards. The risk is still accounted for in the Mean, but now we can add stories points to fill up our velocity.

What about commitment? I think most Agile practitioners agree that iterations are a soft commitment. If the team doesn't get all the stories done, that's okay. Next iteration they may get extra stories done.

Business Decisions

Managers manage risk. It follows that managers need to know the risks. The normal distribution above speaks volumes about risk.

From the table wen can make several claims:

The bell curve is also very telling.

Once thing you could do is ask the coders to spend a week on spikes, exploring the unknowns in the project. By the end of the spike the coders, armed with new knowledge, should be able to revisit the estimates and narrow the curve. That would reduce the risk that managers need to manage.

What about is a great tool. You should check it out.

Maybe the 3-point estimates on suit your team better.

You have options.

Links and References