Re: [scrumdevelopment] Big Picture at the Daily Scrum
- Mike Kenny <mike.kenny@...> writes:
> On Thu, 2006-06-01 at 21:31 -0700, Kevin Dalley wrote:Yes, I think that there were separate tasks all along. There was one
>> After some effort, I split mine into 4 tasks and started working on
>> task 1. This almost meets Ron's 1/5 suggestion. Initially, there was
>> a feeling that I didn't need to stage the big task like this.
>> However, after a day or two, 3 out of the 4 tasks were dropped from
>> the sprint as unnecessary. Unfortunately, task 2 remained, and I had
>> been working on task 1.
> The fact that occasionally it is possible to split a large task into
> smaller components isn't, of itself, that surprising. It often happens
> that the granularity of the requirement is not appreciated until work
> starts. What I do find amazing is that, having realized that the task
> could be split into four it was then possible to drop 3 of these four.
> To me this implies that the original large task was composed of
> unrelated smaller tasks and that these should never have been seen as
story initially, which was handed to me. Today, on the last day of the
sprint, we discovered that the QA end to end test for this item
doesn't quite test the task. Obviously, there is a desire to change
It's simple to say that the requirements shouldn't change during the
sprint. However, there is a hard requirement that the requirements
for a certain customer be ready for testing in 2 or 3 months. If the
requirements are not met, the customer is lost. Unfortunately, the
requirements are not well understand. 1 month sprints may not really
leave enough time between sprints to adapt to our changing
understanding of the requirements. On the other hand, changing
requirements other day would be frustrating. What's the solution?
One week sprints, then reevaluate every week. One day sprints?
> 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