

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®. We’re proud of it. Here’s why…
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.
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.
- Every team member has a deck of cards, each with a different estimate number (often the Fibonacci Sequence)
- A story is presented to the team and estimation begins.
- Each player considers the story and selects appropriate cards to represent their estimate for that story, without talking.
- One by one the players hold up their selected cards, backs forward so no one can see. Suspecting glances float around the table.
- When the last player holds up their cards, the tension is released as everyone reveals their cards (estimates).
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):
- Iteration meeting are help on a video chat, Zoom or Google Meetings
- A story is presented to the team and estimation begins. Same has before….
- Each player considers the story and secretly writes down their estimates, and says “Ready!”
- Some people say “Done!” at the same time, and we’re not sure when everyone has said “Ready!”
- One team member volunteers to take role-call: “Nick?”, “Ready!”, “Micah?” “Ready!”, “Tadd?” “Ready!”, ….
- When we’ve confirmed that everyone is ready, the volunteer takes roll call again, this time collecting estimates.
- “Nick?” “1 2 5”, “Tadd?” “1 1 3” meanwhile the volunteer writes down everyone’s estimates
- Everyone patiently waits while the volunteer crunches the numbers: “Okay the average is …”
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.
“What is an estimate?” Careful! There are multiple answers.
- Coder: “An estimate is a guess. It’ll probably take me two week to build that story.”
- Manager: “An estimate is a commitment. The coder told me it would be done in two weeks.”
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.
PERT
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:
- Optimistic: Everything goes perfectly. No interruptions. No complications. Life is great!
- Realistic: Typical complications arise. Meetings happen. Acceptance criteria tweaked. You know how it is.
- Pessimistic: Race-conditions! Network outage! Obfuscated code! Pandemic! Lions! Tigers! Bears! Oh My!
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.
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:
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.
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:
- It is possible, although highly unlikely (2.3% chance), that the team will finish the project within 5.4 weeks, costing up to $27,083.
- There’s a 15.9% chance that the team will finish the project within 12.5 weeks, costing up to $62,500.
- There’s a 50% chance that the team will finish the project within 19.6 weeks, costing up to $97,917.
- There’s a 84.1% chance that the team will finish the project within 26.7 weeks, costing up to $133,333.
- There’s a 2.3% risk that the team need more than 33.8 weeks, and $168,750.
The bell curve is also very telling.
- Notice how it is slightly left of center. That’s typical. It means there’s not much room to be more optimistic. 10.8 points is about as good as it gets.
- Whereas the right side of the curve tails off relatively far. Feature creep could stretch out the schedule and increase cost indefinitely.
- This curve is pretty wide. That means there’s a lot of uncertainty. There are a lot or unknowns that the coders are nervous about, things that could cause delays.
- Narrow curves indicate less uncertainly… that the coders see a clear path to completion.
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.
planningpoker.com is a great tool. You should check it out.
Maybe the 3-point estimates on poker.cleancoders.com suit your team better.
You have options.