Re: Sprint Planning and Retro when multi-team on one product backlog
- 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...
--- In email@example.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
> > 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