Re: Sprint Planning Strategy for Disadvantaged Team
- One of the basic ideas of Agile is that you put off doing things you don't
need to do until you really need to do them.
So I wouldn't embark on any pre-project to learn all about the existing
code before you start.
Chances are, at the beginning the choices between including this high
priority item, or that critical item aren't going to be particularly
profound. It will follow that the estimates aren't going to be a crucial
element in prioritizing. No one will care if the 50 hour item breaks down
into 8 tasks averaging 6 hours or 4 averaging 11 or whatever. Put some
ballpark numbers up just so you can get an idea how big a bite you think
you can take in Sprint 1.
The idea is that as you go along, you'll get a better feel for what it
takes. The programmers will get more familiar with the system and the
estimating will get faster, easier and more accurate. By the time anyone
really starts to care about the estimates, they'll be good enough. At the
beginning though, the best thing for the Team is produce something.
Anything. Even the wrong thing, as long as it's well done, complete,
tested and potentially implementable.
If they're producing stuff, then they're not disavantaged any more.
Lawyers' Professional Indemnity Company
- On 11/29/07, andre_simones <scrumdevelopment@...> wrote:
> I was deeply troubled after this. A long conversation with one of the senior engineersIs the team aware of the fact that an estimate is just... an estimate?
> (who is pro-scrum) revealed that the extreme poor code quality requires analysis of the
> current code to occur to decompose. As an example, there was one feature that was
> estimated at about 50 hours. I asked the engineer to decompose this into smaller pieces.
> That decomposition took almost a full day. Wow. I was shocked.
No harm is done if it turns out to be wrong, but the team will learn
to better estimate next time.
Have you considered using story points? These funny
estimating-thingies are especially useful when it's hard to imagine
every task upfront. Read Mike Cohn's book "Agile Estimating and
Basically, you look at the product backlog and pick one of the
smallest stories. Let's call that 2 story points. All other stories
also get point values: if it seems twice as big, it's 4 points. Rule
of thumb is: the larger the story, the less precise the estimate.
Therefore, use for example the Fibonacci sequence to estimate stories
(1, 2, 3, 5, 8, 13, 21, 34, etc..).
The advantage is that you don't have to think of tasks and hours, just
"how big do we think this is".
The first Sprints the team may find out that it over- or
under-committed, but this will level out as they learn to know the
system, the code base, the product owner, etc...
Hope this is of any use to you.
Martin Schapendonk, martin@...