Planning poker - the real epiphany

Intro
Last week I established three good reasons to go with Story Points and why they're so popular. This week I want to talk about one more important aspect of story points and then provide tips on how to get started estimating in Story Points. I find this is a rather big challenge for teams just learning the ropes.

Lets talk
Scrum is a learning framework. It's been designed specifically with Inspect and Adapt points with a very specific purpose. Because estimating is a cross-functional team activity, estimating the backlog is just another opportunity for the team to get together to discuss the task at hand and for the stakeholder or product owner to explain what is expected of the team. This discussion is a great way to build team morale, synchronize expectations and getting everyone singing to the same tune. Because Scrum projects are agile, it’s important that teams engage in discussion to ensure the team stays on the right track. And because the estimation is done in a team setting, the estimate is generally more accurate as it represents a cross functional view of the task size, not just the developer view.

Difficulty
A couple weeks ago, I was helping a company understand how to estimate the backlog. This company is new to agile and I was introducing them to Planning Poker and Story Points. Firstly the idea of Planning Poker was some sort of a joke to them. Second getting them to understand Story Points, a seemingly meaningless measurement, seemed to be a non-starter for them.

Ideal hours first
This is where ideal hours came to the rescue. They were far more able to wrap their heads around ideal hours i.e. if you lock the developers and testers in a room with zero interruptions, how long would it take. I figured that once they got their initial stories estimated in ideal hours down, switching to Story points will be easy as they would have established a scale of reference to compare against. This approach worked really well. They're now into their 3rd Sprint and now that they have an existing scale, whether the number is in ideal hours or story points or dog points for that matter, it really doesn't matter any more. If you're new to agile estimating, and you're having trouble coming to terms with Story Points try this first and then make the switch later.

The real epiphany
Planning poker for them was a real epiphany. What started out as a joke soon turned out to be a really, really rich experience. For the first time in the companies history, there was actual dialog. The biggest benefit came from the discussion that ensued after the first round of cards were played. The two outliers (i.e. the folks that estimated low and high) were asked to explain why the big difference. The dialog and information exchange at that point was extremely valuable. I watched their faces after the first user story was done. It took only 5 minutes. And everyone was in sync. I saw the light bulbs go on in their heads. They have never looked back since.

Planning poker has to be the simplest most effective ceremony ever invented. I highly recommend it. There are also variations of planning poker, check out James Grenning's blog for more details.

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com

Comments

[Dave de Vos]

We just finished our third sprint. We started planning in ideal hours because this was the unit that most of us were comfortable with. We estimate tasks, not stories, because we don't feel confident enough that we can estimate anything that takes more than about 20 ideal hours with enough confidence. We feel we have to break up items that exceed 20 ideal hours.

Along the way we tracked hours spent so we were able to measure that our average working day is equivalent to (almost) 5 ideal hours during the last 15 man months.

We initially estimated that we could do 6 ideal hours per working day during the first two sprints, which turned out to be too optimistic and then we went down to 4 for the third sprint (it was close to 4 in the second sprint, because there were a lot of interruptions), which turned out to be too pessimistic in the third sprint.

At the beginning of the third sprint we started using planning poker. The team has accepted it as a valid and practical estimation tool, but the impact was not nearly as big as in your experience.

[Jack Milunsky]

Thanks for sharing your story. We are also pretty much the same, about 5 ideal hours worth of work gets done each day.

What sort of development do you do? that may offer insight into why Planning poker is not so impactful

[Dave de Vos]

We build an integrated suite of engineering tools for a customer that does large engineering projects as their core business. The system should replace a collection of custom applications that were home grown by the customer during the past 15 years.

Three developers are domain experts with growing software development skills and two developers are external senior developers with growing domain knowlegde (I'm one of the two).

[Jack Milunsky]

Perhaps because you already have a frame of reference, with the existing software, it's possible that your software requirements are more deterministic and so there is more certainty and therefore agreement on estimates

[~Phoenix~]

I am new to my company with 5 yrs experience as a Scrum Master. I have had the hardest time with this company and explaining effort estimations. My previous employment we used the Fibonnaci scale, therefore I introduced it here. The teams get it, the management doesn't no matter how I explain it, therefore they have asked to effort in hours. We will be starting our sprint in a couple of weeks with the new measuring criteria, I am eager to see how it will turn out. There is already an uprising happening from the team. I still battle the relinquishing of control with the management staff. Baby steps.

[Jack Milunsky]

Don't get dis-heartened. This stuff is difficult for regular business folks to understand.

Keep the finonnaci scale but instead of obscure story points, call them ideal hours and explain to the business what an ideal hour is. Ideal hours definitely works for sizing. And I am sure this will help the situation.

Let me know what you think or how it turns out.

Jack