Join the DZone community and get the full member experience.
Join For FreeLast 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
Topics:
Opinions expressed by DZone contributors are their own.
Comments