Re: [scrumdevelopment] Re: Splitting stories in big projects
Uhm, well I usually never do a Scrum of Scrums more than one level.
Also, I always consider it just as one way of coordinating between
teams (and dependencies in requirements is just one reason why you
would want to do that).
Some author coordination methods:
- Join each others daily Scrum (of dependend teams)
- Shared sprint planning (part 1)
- Shared sprint review
- Regular Open Space to solve problems
(let the teams figure out what works best for them!)
Also, a product backlog ought to be on product-level. So Win7 would
have one product backlog. That would be *huge* so ways of scaling that
need to be adopted (e.g. requirement areas), but having 4 levels of
backlogs will (in my experience) lose all visibility and require
people to syncrhonize all the time. Tools won't help with this.
Last, a minor issue. At least in the terminology I've been using, a
feature team is a scrum's Team. So that one is already 5-9 people. I
wouldn't call a group of 40 people a feature team, I guess that would
relate more to a requirement area. But... I assume this is just a
Does this help?
On Nov 20, 2009, at 4:48 PM, matt.evon wrote:
> Thanks for you comments.
> Any comments on my other post's questions which no one has answered
> so far:
> --- In firstname.lastname@example.org, "Juan Banda"
> <juan_banda@...> wrote:
> > Scrum-of-Scrum will probably start occurring spontaneously
> Win7 is composed of 25 feature teams. Would all 25 feature team heads
> participate in Scrum-of-Scrums? It is a big meeting... Should it be
> split into 5
> submeetings and then to one main meeting which compiles the
> Then, each feature team in Win7 has on an average 40 team members.
> Should they
> be split into 8 5-member teams?
> So, do we eventually end up in Scrum-of-Scrum-of-Scrum-of-Scrum at
> the highest
> level of project organization, i.e. do we have 4 level project
> organization? And
> do we have 4 level Product Backlog?
> Do we have daily
> - Scrum meetings
> - Scrum-of-Scrum meetings
> - Scrum-of-Scrum-of-Scrum meetings and
> - Scrum-of-Scrum-of-Scrum-of-Scrum meetings?
> --- In email@example.com, Bas Vodde <basv@...> wrote:
> > Hi Matt,
> > I hate promoting my own book, but... we do cover these problems in
> > detail in the upcoming "Practices for Scaling Agile & Lean". I think
> > we got about 15 pages about splitting stories as this is such a
> > problem for large products.
> > Related to non-functional items such as "speed up Windows". The
> > requirement itself is somewhat vague, as you would optimize
> > aspects of Windows, such as "speed up the start-up", "speed up the
> > etc. For each, on the Product Backlog you could split this in
> > different performance targets "speed up with 1%", "speed up an
> > additional x %". When estimating these, the team will have to talk
> > about ideas of "how" to reach such a target (this is needed when
> > splitting it up). This might require measuring and finding the
> > bottlenecks, which could be an backlog item by itself. (we recommend
> > these kind of items, as long as they provide useful/meaningful
> > information to the PO, such as a 5% increase would cost us X$)
> > One recommendation we sometimes make is to form a requirement area
> > around performance where there are teams which spend almost all
> > time on measuring the system, finding bottlenecks, and optimizing
> > themselves. This avoid some of the issues with the dependencies, but
> > the people in this team will (together, not each individual) need to
> > have a broad knowledge of the overall system. (requirements areas
> > covered in "Scaling Lean & Agile Development", which is already
> > available).
> > Sorry for the self-promotion here :( But I do hope this helps you
> > further.
> > Tnx
> > Bas
> > On Nov 18, 2009, at 10:29 PM, matt.evon wrote:
> > > Splitting stories is basically simple in a one team project. How
> > > about big projects?
> > >
> > > Let's take Windows 7 as an example. One of the stories is "Make
> > > Windows faster" (http://blogs.msdn.com/e7/archive/2008/08/18/windows_5F00_7_5F00_team.aspx
> > > ). There are obviously numerous options for making Windows faster
> > > though only part of them will be implemented. Part of the measures
> > > which will be implemented, require work from many teams. My
> > > are these multi-team stories (which obviously have a very tight
> > > coupling) and the work which is done before the actual
> > >
> > > Here are some questions to which I have not found answers in Scrum
> > > literature:
> > > - How and with whom do you identify the options of making Windows
> > > faster? How and with whom you decide which of the options will be
> > > implemented? Identification of options and selecting which ones to
> > > implement require quite a lot of work (it is not done in a two
> > > Sprint Planning session). Would that work be in a Product/Sprint
> > > Backlog as a story? How do you estimate this kind of story
> (which is
> > > not implementation work)?
> > > - How and with whom do you identify the substories? How and with
> > > whom do you allocate the substories to teams?
> > > - Doesn't this require quite a lot of upfront design (which is not
> > > allowed in Scrum/agile)?
> > > - Doesn't this require quite a lot of collaboration between teams?
> > > Do you have all developers (about 1000 of them) in sprint planning
> > > of these end-to-end stories?
> > > - Doesn't the story (making Windows faster) create dependencies
> > > between teams? How do you handle them (Scrum literature says that
> > > "Get rid of dependencies", but it does not work here)?
> > >
> > > Does anyone in this forum have real life experience in solving
> > > mentioned issues?
> > >
> > >
> > >