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

Re: [scrumdevelopment] Re: Splitting stories in big projects

Expand Messages
  • Bas Vodde
    Hi, 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
    Message 1 of 6 , Nov 20, 2009
      Hi,

      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
      - etc.
      (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
      terminology issue.

      Does this help?

      Bas



      On Nov 20, 2009, at 4:48 PM, matt.evon wrote:

      >
      >
      > Bas,
      >
      > Thanks for you comments.
      >
      > Any comments on my other post's questions which no one has answered
      > so far:
      >
      > --- In scrumdevelopment@yahoogroups.com, "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
      > submeetings?
      >
      > 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?
      >
      > Matt
      >
      > --- In scrumdevelopment@yahoogroups.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
      > common
      > > problem for large products.
      > >
      > > Related to non-functional items such as "speed up Windows". The
      > > requirement itself is somewhat vague, as you would optimize
      > different
      > > aspects of Windows, such as "speed up the start-up", "speed up the
      > x"
      > > 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
      > their
      > > time on measuring the system, finding bottlenecks, and optimizing
      > them
      > > 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
      > are
      > > 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
      > concern
      > > > are these multi-team stories (which obviously have a very tight
      > > > coupling) and the work which is done before the actual
      > implementation.
      > > >
      > > > 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
      > hour
      > > > 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
      > above
      > > > mentioned issues?
      > > >
      > > >
      > > >
      > >
      >
      >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.