Re: [scrumdevelopment] Big Picture at the Daily Scrum
- I'm not sure that urgency and commitment are the issues. The problem
is that the group is surprised by not meeting the goals of the sprint.
Unfortunately, until a task is finished, a developer doesn't know for
sure that it can be completed.
When nearing the end of the sprint, it is tempting to believe that I
can finish a task even though I am not as far along as I had hoped to
be at this point. Am I lying to myself? Do I lack commitment? Am I
too optimistic? Maybe all of the above. Of course, sometimes I can
pull of a miracle and finish a 2 week estimate in 2 days. On the
other hand, I can report my doubts in the sprint meeting.
If someone reports falling behind in the sprint, what is the reaction
of others? Can they come together and help solve the problems? Are
they willing to report that a task may slip in the current sprint?
If the reaction of the other sprint members is to talk about
commitment and urgency, a developer may be encouraged to report that
everything will be finished at the end of the sprint.
What is nice about scrum is that at the end of the sprint, there is a
near-deliverable. No one knows at the beginning of the sprint exactly
what will be delivered and what will wait, but everyone knows the
goals, and that the product will be nearly usable at the end.
Some tasks will have to wait until the next sprint.
Improving estimates in the end of the sprint would be nice, but accept
"Ronica Roth" <ronicaroth@...> writes:
> Which helped me finally nail down a question I've been trying to
> formulate. Our daily scrums have improved to the point where the team is
> communicating with one another (not at the scrummaster), and members are
> faithfully reporting what they did, will do, and problems. But I don't feel
> like they have any sense of whether they will succeed in completing the
> iteration. Despite burndown charts and the iteration dashboard (we use Rally),
> the amount of work *not* getting accomplished by the end of iteration always
> seems a huge surprise.
> How can one improve the team's sense of the big picture, as well as the
> urgency/commitment around completing the iteration?
> On Friday, June 9, 2006, at 7:49:00 AM, Hubert Smits wrote:I'm not Hubert, but *we* are definitely burning *and working* backlog items.
>> Ain't you also working down to zero /in a Sprint/? I have x folks who
>> have y days remaining in the sprint, so I can burn x times y days. If
>> the amount of work at any given day exceeds this number I have
>> something to think about. I have to add though: I am thinking from
>> 'pure scrum' perspective - no change of scope during the sprint.
> Don't your teams add and remove tasks during the sprint? Or are you
> burning backlog items, even though the team is working tasks?
We still use tasks for estimation, and they seem to be helpful; but when we
try to work them, we almost invariably find that we need to break down the
work differently from the breakdown for estimation, and that we can't really
plan how to break the work itself down into meaningful tasks.
Perhaps it's just us...
"Information Radiation in Practice -
Communication Tools for Colocated Teams"
Tutorial at the XP2006 conference, Oulu