Re: [scrumdevelopment] Too much time on estimation...
- ballymacaward wrote:
> However, in the review meeting many of the team members are complaningOne initial questions is, did the team discuss the relative
> that too much time is being spent on estimation and that that the daily
> scrum is focusing too much on the burn down chart.
costs and benefits from the time they are spending? I get the
team feels the costs are too high for the benefits. Who is
making the team spend the time on estimating and focusing on
the burn down? What are their reasons for doing so? Have they
tried not doing it? What happened?
What type of estimation are you referring to? Estimating product
backlog items? Estimating tasks during the sprint? Or are you
referring to the overall sprint planning activities? How much
time is being spent?
It's hard to comment without knowing more about what it is they're
complaining about. Product backlog planning often has a cluster
of time spent early in a new Scrum project, and then some level of
ongoing work to handle new items and feedback. I see teams doing
sometimes a day or two of initial backlog planning, and then maybe
a half day a month or less of ongoing work. Maybe a re-planning
session if they learned something from early sprints and want to
go back through the backlog again.
Sprint planning really does take about a day for a month sprint.
Once the team gets experienced at it, and if the project has some
stability to it, I've seen some teams get it down to a half day.
The actual task planning part (the second part) seems to take from
2 to 6 hours, depending on the team size, project complexity,
stability, experience, etc., etc.
Does the team go through the three questions in the daily scrum?
What else is happening that focuses on the burn down? Does the
team update their time remaining each day? Are they doing that
during the daily scrum?
Some checking into the burn down is healthy. The primary focus
should be on the current tasks and the next moves, and I would
expect each team member to speak in terms of the things on the
The team of course needs to poke their heads up every few days
to see how they're progressing for the sprint as a whole. If
the actual burn down is deviating too much from what would be
needed to hit the sprint end, they need to do a little re-planning
to decide how to reach a good closure for the sprint. But there
is no reason to be spending time analyzing the burn down and doing
that re-planning every day.
> In fact the scrummaster may be trying to micro manage too much. HasTell us more of the story. It's hard to diagnose and compare
> anyone else had this difficulty and would they be able to offer
> suggestions on how to resolve this.
without a little more information. Perhaps the ScrumMaster
seems to be micro-managing because they aren't getting the
feedback they need, or aren't experienced using the tracking
mechanisms, or they don't feel the team is paying attention,
or ??? -- lots of possibilities...
Paul Hodgetts -- CEO, Coach, Trainer, Consultant
Agile Logic -- www.agilelogic.com
Training, Coaching, Consulting -- Agile Processes/Scrum/Lean/XP
Complete solutions for adopting agile processes, Scrum and XP.