Estimation Techniques

[Sharon Cichelli]

Hi, Gang,
Anthony asked for input on estimation techniques, so here's a conversation seed.

What kind of estimation did y'all have in mind? I see three levels
that might be of interest:
1) When a team is making a sprint commitment, how do they know that
they're agreeing to something they can finish?
2) When a product owner is preparing a press release for what features
will be released next quarter, how does he or she know what's feasible
to project and with what level of confidence?
3) During a sprint, how do you judge whether you're on-track to meet
your commitment, versus veering off course and needing to correct or
adjust?
4) Are there others you were envisioning when you brought up the topic?

I've noticed that teams will latch onto planning poker--with story
points on playing cards--because that's visible and tangible, but be
left with questions about what stage it applies to, what it's for, and
how it actually tells you anything useful.

I've also seen wideband delphi incorrectly presented as an estimation
technique, when it is instead a consensus-building technique. It
allows participants to independently make their own estimates and each
be equally heard, but it doesn't inform how participants are making
those estimates.

What topics around estimation are you interested in exploring?

Cheers,
Sharon

[ncancelliere]

I think definitely cover the differences in estimating in points vs
hours. Using planning poker to help eliminate peer pressure with
estimates. Focus on estimates being just that - estimates - not
commitments. Maybe touch on velocity and how estimation equates into
velocity and helps the team plan better over time.

I find in my own experience a lot of people (especially business
managers) do not understand why even use story points vs. hour
estimates.

Nick



On Jan 30, 11:24 am, Sharon Cichelli <sha...@invisible-city.com>
wrote:

[Scott Bellware]

Is anyone using a management model other than that of Scrum and XP?

I'm throwing this out here because Kanban is now starting to show
initial signs of its entrance into mainstream agile contexts (groups,
conversations, articles, books, etc), and it takes quite a different
tack on estimation and work management.

Is anyone else in the group shifting into Kanban or thinking about it?
Any reflections on using leveling and scheduling rather than story
estimation and timeboxes?

best,
Scott

[Sharon Cichelli]

I would really like to learn more about Kanban estimation techniques.
It seems like such a paradigm shift. Even without being on a Kanban
team, seeing a significantly different way to think about a shared
challenge can spark epiphanies and insights. I had thought Lean was
synonymous with Kanban, but something John H. said the other day made
me realize these are separate concepts. Scott, do you have a Kanban
primer you like to recommend?

Thanks,
Sharon

[Scott Bellware]

Cory Ladas' blog is probably the most consolidated collection of
Kanban writing for software:
http://leansoftwareengineering.com/

-Scott

[Bish...@gmail.com]

Howdy Folks.

First I apologize for my "newbie-ness" in regards to estimation. I've helped a handful of teams use planning poker and wide-band consensus during release and sprint/iteration planning.

I think it might be difficult to talk about estimating without referring to "when" the estimating is done, right?

So, referring to the original seed, I would say #2, would be around release or multi-sprint planning. I might consider planning poker for stories which can be sprinkled throughout the release(s).

Question: Shouldn't the Product Owner consult with the Team before a gummy bear "estimate" is given?

#1 could employ poker on the tasks during sprint iteration. When there is a strong opinion in the room, poker helps offset the pull he/she has on the group.

Question: In subsequent sprint iterations, wouldn't i want to review my tasks to see if there any re-usable tasks for historical

#3, we are talking about the day to day tracking, right?

Thoughts?

A.

[Scott Bellware]

> I think it might be difficult to talk about estimating without referring to
> "when" the estimating is done, right?

"When" is definitely an important factor. Estimates can grow less
accurate the further ahead of the start of the implementation work.

> Question: Shouldn't the Product Owner consult with the
> Team before a gummy bear "estimate" is given?

Unless the product owner is the team's design and implementation lead
he should consult at least with the design and implementation lead.

> Question: In subsequent sprint iterations, wouldn't i want to review my
> tasks to see if there any re-usable tasks for historical

You always want to continue to apply lessons learned, but a task done
in the past that is similar to a task that you're about to do is in a
different context. The effort needed to get work done is influenced
by the work already done. Existing code, dependencies, structures,
behaviors, etc will affect the work needed to get a pending task done.

There's no such thing as a pre-cooked and canned estimate. Work that
you're about to do has to be considered in the context within which
you're about to do it.

best,
Scott

> &gt
> >
>