Loading ...
Sorry, an error occurred while loading the content.

Re: Sprint Planning Strategy for Disadvantaged Team

Expand Messages
  • David A Barrett
    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
    Message 1 of 13 , Dec 4, 2007
    • 0 Attachment
      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.


      Dave Barrett,
      Lawyers' Professional Indemnity Company
    • Martin Schapendonk
      ... Is the team aware of the fact that an estimate is just... an estimate? No harm is done if it turns out to be wrong, but the team will learn to better
      Message 2 of 13 , Dec 5, 2007
      • 0 Attachment
        On 11/29/07, andre_simones <scrumdevelopment@...> wrote:
        > I was deeply troubled after this. A long conversation with one of the senior engineers
        > (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.

        Is the team aware of the fact that an estimate is just... an estimate?
        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
        Planning".

        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.

        Regards,
        Martin

        --
        Martin Schapendonk, martin@...
      Your message has been successfully submitted and would be delivered to recipients shortly.