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

Re: Sprint Planning and Retro when multi-team on one product backlog

Expand Messages
  • martinrajotte
    Thanks for sharing your experience. I ll keep the idea of not doing task estimate for the future. However, I don t think the teams are ready yet for such a
    Message 1 of 5 , Jun 23, 2010
      Thanks for sharing your experience.

      I'll keep the idea of not doing task estimate for the future. However, I don't think the teams are ready yet for such a "relax" process. It is already a strech for them to not capture the "Completed work"... The Sprint Burndown is also a good tool, although I agree that some teams could do without estimates. However, I feel that having a short term goal also helps to assess our progress.

      I might try it with an experienced agile team to see how it goes...

      Martin Rajotte
      Incycle Software

      --- In scrumdevelopment@yahoogroups.com, William Wake <william.wake@...> wrote:
      >
      > On Mon, Jun 21, 2010 at 3:57 PM, martinrajotte <
      > martin.rajotte@...> wrote:
      >
      > > Context
      > > I'm currently implementing Scrum in a team where we need to split the
      > > existing team in 2 because of the number of individuals (14). They are
      > > working on the same product and will be sharing the PO.
      > >
      > I had a group do the same thing for the same reason. I think it's an awkward
      > size either way.
      >
      > > Questions
      > > Sprint Planning
      > > I understand that the Sprint Planning session is done with all teams
      > > members together. Does this include also the decomposition of Product
      > > Backlog Items into Sprint Backlog Items? Or do they split and reconvene
      > > later once the tasks have been detailedÂ… If they do the decomposition all
      > > together, who votes for tasks estimates only the team that will take the
      > > PBI?
      > >
      > We did a shared demo and retrospective, then the story-level planning
      > together. We basically used velocity to get an overall number of points,
      > chose the most important stories, then spread them across two boards to the
      > two teams. It was usually easy enough to divide them up; usually there was a
      > theme that made one group pick a majority of its stories.
      >
      > We had an easy approach to task estimates - don't do them. We would just
      > eyeball everything at the end for plausibility.
      >
      > >
      > For decomposing (this group broke stories into tasks), we might have done it
      > as a large group once or twice, but quickly decided to let the teams manage
      > it separately. We had month-long sprints, and we went to a "Monday morning
      > task meeting" with an extra meeting later in the week if the tasks got
      > finished early. (This evolved a bit more into a "task out 2 or 3 stories at
      > a time, with a Monday checkpoint.) That evolution felt like the right
      > thing.
      >
      >
      > > Sprint Retrospective
      > > In a case where there is two team, are separate retrospectives appropriate
      > > followed with some coordination?
      > >
      > We mostly did retrospectives jointly on a monthly basis. Teams had some less
      > formal discussions on their own. Looking back, we probably could have
      > balanced that better.
      >
      >
      > --
      > Bill Wake
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.