... What would happen if your tasks were, oh, 1/5 the current size? Ron Jeffries www.XProgramming.com Improvement stops when we start believing that ideasMessage 1 of 65 , Jun 1, 2006View SourceOn Thursday, June 1, 2006, at 7:51:47 PM, Kevin Dalley wrote:
> I'm not sure that urgency and commitment are the issues. The problemWhat would happen if your tasks were, oh, 1/5 the current size?
> 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
> some unpredictability.
Improvement stops when we start believing that
ideas about how to improve are insulting.
... I m not Hubert, but *we* are definitely burning *and working* backlog items. We still use tasks for estimation, and they seem to be helpful; but when weMessage 65 of 65 , Jun 11, 2006View Source
> 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