Re: [scrumdevelopment] Re: How do you choose an iteration length?
- Very quick reply - to me this is big smell tasks that can't broken down. If you look at any of Poppendieck's books you will see the effect of task size. In you're next retrospective I would survey team members to find out why tasks are so large and take steps to break them down. Repeat until the average task size is less than 8hrs.
MarkOn Wed, Feb 25, 2009 at 4:30 PM, jpetrangelo1 <jeanne@...> wrote:
--- In firstname.lastname@example.org, Mark Levison <mark@...> wrote:Thank you for questioning these assumptions! This one is one I've
> On Wed, Feb 25, 2009 at 3:53 PM, jpetrangelo1 <jeanne@...> wrote:
> > Advantages of longer iterations:
> > - Less overhead.
> Really what makes you say that? The meetings scale with the length of
> the sprint. I'm not sure what other overhead you can find. Please
heard around so I passed it on. The assumption is that meeting lengths
(iteration planning, retrospectives, etc.) would be capped because
people can't tolerate very long meetings. Thus the meetings wouldn't
really scale. Of course the corollary is if you don't give yourself
the time you truly need, your meetings aren't going to be as effective.It would be people's natural tendencies here to create chunks of work
> > - Work can be broken down into longer units, which might be a better
> > fit for certain environments. For example it may just not be realistic
> > to have work that takes half a day to two days to complete, versus two
> > to four days. If you need longer work items, it's a challenge to pick
> > a good set of work that fits in a shorter iteration. This seems more
> > of a technical limitation that might end up being the deciding factor.
> Why would you tolerate work being done in such large chunks? What
> stops it being broken down? I'm interested because I've yet to see
> work that couldn't be broken down in chunks of less than a day.
that take 2-5 days, because our traditionally managed tasks are
typically 3 days to two weeks. Why? Because breaking it down more than
that makes Gantt tracking even more painful. So people here are
assuming breaking down the work chunks to 2-5 days is really tiny, and
less than that is absurdly small. I might add that seeing examples
from non-embedded projects does not have any influence. In our build
environment, it takes 15 minutes to build with no changes at all, and
you don't even want to know how long it takes for a full build with
changes (hours). That won't change, even if we could get our unit
tests to run on the host instead of the target, allowing us to avoid
the time consuming step of downloading sw to the target in order to
see it run. Depending on the hardware configuration, I may need to
let my build go overnight before I can run it. If you don't count the
build step, the work might take less than a day, but in the meantime
my ability to tackle other tasks (multitask) is similarly limited.
Recent Entries: Agile/Scrum Smells: http://www.notesfromatooluser.com/2008/06/agilescrum-smells.html
Agile Games for Making Retrospectives Interesting: http://www.notesfromatooluser.com/2008/10/agile-games-for-making-retrospectives-interesting.html