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

Re: [scrumdevelopment] Sprint Planning Strategy for Disadvantaged Team

Expand Messages
  • Jeff Myers
    This sounds like a perfect situation for Sprint 0, Your first sprint should be all about understanding the project/code. You don t mention your sprint duration
    Message 1 of 13 , Dec 3, 2007
    • 0 Attachment
      This sounds like a perfect situation for Sprint 0,
       
      Your first sprint should be all about understanding the project/code.
       
      You don't mention your sprint duration but I don't think that really matters in this instance.
       
      you also don't mention the actual number of team members. 
       
      If this was my team/project I would sit down on the first day and try and break the project down into areas, you don't describe the product bu I am going to make the assumption that the functionality can be broken down into at least 5 general areas.
       
      Depending on team size I would try to put two people on every section for the deconstruction, pairing senior developer with Jr developers or QA.
       
      Target being that at the end of the Scrum the team has an understanding of the existing code and will know how to develop the rest of the plan.
       
      I know this is massively oversimplified but I don't know how you can have a meaningful conversation with the Project Owner about schedule until this step is taken.
       
      jeff

       
      On 11/29/07, andre_simones <scrumdevelopment@...> wrote:

      We are currently in the midst of implementing Scrum on a pretty large project. Below are
      some of the disadvantages we are experiencing now.

      - The code base is about 10 years old and is pretty big.
      - All of the original developers are gone. The majority of the developers have been
      working on the project less than a year.
      - The entire QA team is comprised of new hires, many only 2-3 months tenured. Many of
      them are new to QA.
      - The full functionality of the product is not fully understood by anyone.
      - The poor quality of the code is profound. TDD is nearly impossible, and a re-
      architecture is inevitable (but this is down the road), as the code base is PowerBuilder
      (wow, its hard to find PowerBuilder resources).

      The list goes on, but these are the key points that impact the Sprint Planning session.

      It took a while, but we found a strong product owner who created a prioritized product
      backlog. After this, we attempted to have a sprint planning session. It was pretty painful.
      In my previous teams, the team members were all very knowledgeable about the code
      base and its functionality. In addition, the code was structured pretty well, so the PBL
      could be decomposed relatively easily in one sitting.

      In this sprint planning session, the team thought of decomposing these features (stories)
      into 16 hour or less tasks as a ridiculous notion. They kept saying that they would have to
      perform analysis to do this decomposition. They absolutely had no clue how to
      decompose.

      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.

      This means that the way the sprint planning session is conducted will have to be adjusted.
      Right now, the team will not be able to sit in a room and decompose these tasks in one
      planning session. I am leaning towards having a pre-planning session. Where the team
      assigns "homework" to themselves, to come prepared for the sprint planning session for
      the purpose of coming up with a sprint backlog and a commitment. Over time, as the
      team becomes more experienced, I think that this will get better.

      I'd love to hear some thoughts of some of those who've been in this situation before.

      Andre


    • 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 2 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 3 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.