--- In firstname.lastname@example.org
, Ron Jeffries
> On Thursday, June 1, 2006, at 9:10:53 AM, Victor Szalvay wrote:
> > David has done a nice job clarifying my point. I don't like metrics
> > at the sprint task level at all, especially metrics that try to imply
> > whether the team is going to finish the sprint *for them*. This
> > should be a call the team makes considering the history of the sprint
> > to date (recorded as the burndown), what is left to do, and the
> > risk/uncertainty impacting the sprint currently.
> > If the ScrumMaster wants to draw a trendline then I would be
> > suspicious about the liberties they are taking in making assumptions
> > from that trendline. If the team wants a trendline then again I think
> > something is wrong because the team is asking for a crutch to tell
> > them how things will turn out in the sprint. In my experience, Scrum
> > teams know how they are doing each day if there are well-run daily
> > scrum meetings and generally good communication across the team.
> Victor, most every gig I've had in the past two years has been
> helping teams who cannot get done, by the end of the sprint,
> everything they commit to at the beginning. They think they're doing
> well every day, right up to the last day, and yet, they don't have
> software ready to go.
> How would you suggest that such teams should be helped?
> Ron Jeffries
> Do as you will, try to do it well. That's what I do.
I hope your question is rhetorical because clearly I can't answer
something in a yahoo group posting that you've not been able to
achieve in 2 years of work.
I agree this is a problem and I see it often myself. I don't think
dumping additional metrics on top of the sprint burndown is going to
solve this problem though.
One thing I notice in common with most teams that don't finish on time
is that they aren't working "together" on backlog items/stories.
They are usually smart and as such try to be efficient about the
sprint work. So instead of teaming up and working on a single item at
a time, they divide up the backlog items amongst themselves and go to
work individually (sometimes in pairs) on separate backlog items.
So I try to stop them from worrying about being locally "efficient"
and start thinking about getting a single backlog item "Done" (really
done) before moving on to the next. Basically, bring in some lean
principles like optimizing for the whole. This shows individuals on
the team that they do need to spend a lot of time talking through the
definitions of done, communication with each other about assumptions,
etc. Once they can finish an item at a time they can start getting
fancy with parallelizing backlog items.
Even then, some teams go back to trying to be efficient and
subsequently rarely finish anything to the satisfaction of the PO.