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

Re: [scrumdevelopment] Multi-Team Backlog Planning

Expand Messages
  • Henrik Kniberg
    I ve had most success combining the two approaches, although closer to B. 1. PO prioritizes the product backlog 2. Make a preliminary team subdivision, with
    Message 1 of 2 , May 6, 2007
    • 0 Attachment
      I've had most success combining the two approaches, although closer to B.

      1. PO prioritizes the product backlog
      2. Make a preliminary team subdivision, with the goal of having right-sized teams that are reasonably independent of each other. Somebody in the project is responsible for this, be it the PO or SM or manager or whoever.
      3. Everybody meets for sprint planning, product owner goes through the top items in the product backlog.
      4. Each team grabs items from the product backlog, determining what to work on during the next iteration.
      5. During the meeting, teams may be rearranged further by the teams themselves.

      Each step 1 - 5 is repeated for each new sprint. Quite a lot of changes and overhead the first few sprints, but this is a learning period. After a few sprints things stabilize as the teams learn what works best. More specifically, they learn which team combinations work best, and which teams should be working on which parts of the product backlog.

      So basically, yes, we try to do long term team allocation but the plan is reevaluated each sprint (just like all other plans in Scrum).

      This worked well with a team of about 30 developers (we tried several other approaches before settling on this). There is probably a limit to how much this approach scales though.

      /Henrik

      --
      Henrik Kniberg
      http://www.crisp.se
      +46 (0)70 492 5284

      On 5/6/07, Andy Powell < andy.powell@...> wrote:

      For product backlogs that are being worked on by more than one team,
      which process do you follow and why?

      Process A:
      1. Determine what will be worked on in the release.
      2. Determine what will be worked on by each team in the release.
      3. Each team determines what it will work on for each iteration.

      Process B:
      1. Determine what will be worked on in the release.
      2. Determine what will be worked on in the next iteration.
      3. Each team determines what it will work on for that iteration.

      I'm sure there is some overlap between this two processes. The
      question I'm curious about is how soon in the process do you start
      assigning stories to teams?

      From a lean software development standpoint, you'd try to do it as
      late as possible and follow process B. I can also see how spending
      some time thinking about dependencies at the release level could be
      more efficient than rethinking dependencies every iteration.

      Thanks for your input.

      Andy





    Your message has been successfully submitted and would be delivered to recipients shortly.