Planning Poker - The Real Epiphany
Planning Poker - The Real Epiphany
Join the DZone community and get the full member experience.
Join For FreeAdopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap. Brought to you in partnership with Techtown.
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 or visit blog.agilebuddy.com
Take Agile to the next level with DevOps. Learn practical tools and techniques in the three-day DevOps Implementation Boot Camp. Brought to you in partnership with Techtown.
Like This Article? Read More From DZone
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}