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

Re: Multiple Teams - Single Product Backlog

Expand Messages
  • momofromthablock
    Here s how we do it: 45 people project, one backlog, 4 subteams, 2 teams working on the same features, the other 2 teams working individually on separate,
    Message 1 of 25 , Jun 22, 2010
    • 0 Attachment
      Here's how we do it:

      45 people project, one backlog, 4 subteams, 2 teams working on the same features, the other 2 teams working individually on separate, broadly interdependent features.

      - teams starts by doing the retrospective of previous sprint. the 2 teams that work on separate features do it separately, the other 2 teams that work on the same features do the retrospective together. at the end of the retrospective all 4 teams share the pluses and the deltas together as one big group, outlining the ones that impact everybody. (30-40 min)
      - product owners (2) outline the goals for the next sprint with all the 4 teams and enumerate (and lightly discuss) all the stories that the teams will be working on in the next sprint so that everybody's on the same page on what they're working on next. there is no need to go into too much detail here, because the stories are previously discussed in greater detail during backlog "grooming" meetings which happen before each sprint starts (30-40 min)
      - each subteam decides on what stories they'll work next and then they task them out individually, at the subteam level. whenever questions arise, they just ask - the entire sprint planning happens on an open floor. (2-3-4 hrs)
      - scrum masters (4) calculate capacity for each subteam, dependencies, contingency needed etc.(15 min)
      - each subteam regroups and commits on the work for next sprint. (30 min)

      Hope this helps.

      Andrei

      --- In scrumdevelopment@yahoogroups.com, Ed Kraay <ekraay@...> wrote:
      >
      > Hi Pete,
      >
      > Thanks for the two real world examples here. I'm starting to see how
      > this could possibly work, and what some of the pros and cons are. I
      > would tend to favor the second case, because teams would be able to
      > get the clarification of planning poker.
      >
      > Did you have any weirdness with management attempting to compare
      > velocities across teams?
      >
      >
      > Ed
      >
      > 415-694-9653 (us)
      >
      > Sent from mobile.
      >
      > On Jun 15, 2010, at 11:24 AM, "PeterG" <peterg@...> wrote:
      >
      > > Hi Ed,
      > >
      > > We've done this on several projects at Adobe. A few approaches we've
      > > tried:
      > >
      > > A 30 person project, single Product Backlog, 4 scrum teams. Each
      > > scrum team started out by doing duplicate (quadruplicate?) estimates
      > > for seven or eight stories. They then each sent one person to a kind
      > > of scrum of scrums planning poker where they all came in and in the
      > > first round of voting, voted based on their team's understanding,
      > > but then used the standard planning poker process for the subsequent
      > > rounds of voting. This established some baseline stories.
      > >
      > > From there on out, they divided up the remaining product backlog and
      > > estimated compared to the shared baseline stories.
      > >
      > > This worked fairly well, it got them "close enough" so that any team
      > > could pull a story in to a sprint and the relative size was pretty
      > > good.
      > >
      > > We lose one of the advantages of planning poker (team consensus on
      > > what a story really is) when we allow one team to estimate its size
      > > but another team to actually develop it. This was the tradeoff we
      > > accepted in this case due to the business needs.
      > >
      > > Another team, about 50 developers, 6 scrum teams, just started up
      > > doing scrum. They divided the backlog into six various areas that
      > > were relatively decoupled, then had a group of leads/managers
      > > establish some baseline stories from prior releases. The scrum teams
      > > then tagged stories that they thought they were likely to work on
      > > and estimated those compared to the shared baselines. They made it
      > > explicit that just because a team had estimated a story, that didn't
      > > mean they had to pull it into a sprint if there was a good reason
      > > for another team to grab it during planning, but in most cases the
      > > team that estimated would end up pulling that story.
      > >
      > > So far both of these approaches has worked pretty well -
      > > stakeholders had a decent idea of what the scope of the release
      > > would be, the teams got to dig into the overall release plan, but it
      > > was light weight enough that no one is concerned if we toss stories,
      > > replace them, re prioritize etc.
      > >
      > > Peter Green
      > > Agile Coach & Trainer
      > > Adobe Systems, Inc.
      > >
      > > --- In scrumdevelopment@yahoogroups.com, "ekraay" <ekraay@> wrote:
      > > >
      > > > Hi,
      > > >
      > > > I'm in a multiple team environment and we are looking to go with a
      > > single product backlog for multiple teams. I've read the literature
      > > on this (Cohn, Larman/Vodde). I've successfuly scaled Scrum before
      > > with multiple product backlogs and many teams and done x-team
      > > release planning. I know this creates sub-optimization on the
      > > feature teams. My question with this, for those who have actually
      > > done it, is how do you handle estimating items on the product
      > > backlog across teams on this shared Product Backlog? How do you do
      > > release planning?
      > > >
      > > > A) Did you estimate these PBI's with representatives for the
      > > multiple scrum teams?
      > > > B) Did you have everyone estimate these PBI's as a group? If so,
      > > how did you handle velocity for each team.
      > > > C) Did your teams only estimate the items in the PB that they are
      > > going to pull into the next sprint? (If so, then how do you get a
      > > sense of what will be done by the next release)?
      > > > D) Others?
      > > >
      > > > Thank you,
      > > >
      > > > Ed Kraay
      > > >
      > >
      > >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.