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

26891Re: The Scrum Release Plan Dilemma

Expand Messages
  • mpkirby
    Feb 6, 2008
    • 0 Attachment
      aacockburn wrote:
      >
      > Personally, I think that you should always have a coarse-
      > grained statement of time and content goal (and everyone
      > on the team should know it). If you are missing that, then
      > it is hard for everyone on the team (including the sponsors)
      > to pull in the same direction.
      >
      > Does this help you out at all?


      We create a backlog of "epic's" with short descriptions. Each epic is
      prioritized by the product owner, and then each of the teams will "bid"
      on how much effort it would take to implement the feature. We use a
      generic "complexity point" for each team.

      Each release is usually around 12 weeks (with a number of weeks
      afterwards for hardware/software wring-out, as well as other subsystems
      (the physicists) getting a chance to validate algorithms).

      After each team is "full" the scrum teams will work with the product
      owner (in this case we use product-owner proxies into a systems
      engineering organization because of the size of group). to break the
      epics into reasonable sized chunks. Most scrums use a two week
      iteration. I suppose if you squint, you could say we have a 1 week task
      cycle on top of that.

      The stories get planned (allocated to iterations), until the teams
      basically considers themselves full. At this point we might prioritize
      some of the lower priority stories out of the release all-together. We
      write customer acceptance tests for the stories for the upcoming
      iteration, and break them down into tasks ( we estimate tasks and
      stories in hours, not story points).

      During the development the product owner and team work together to
      prioritize and adjust the stories associated with the epic based on the
      demo's at the end of each of the two week iterations. The general rule
      is that we can change the scope and mission of the epic (for future
      iterations) as long as we don't exceed the original allotment of effort
      for the epic.

      So, for example, if we estimated an epic as a "High" (approximately 600
      hours), we would allow changes to stories and additions and deletions so
      long as we don't exceed 600 hours. If we exceed 600 hours, we have to
      go back through the organizational balancing process to get more work
      tokens. (typically dropping something off our release plan, not just the
      scrum team's backlog.).

      I hope this (rather short and terse) description of what we do was
      helpful. For larger organizations the biggest problem I have found is
      maintaining the sense of commitments. Working software every two weeks
      helps, but it isn't a substitute for a little bit of forward thinking on
      what you plan to deliver. This is particularly true when there are
      other groups that depend on your deliveries to make the product (e.g.
      hard tooling in manufacturing, mechanical and electrical design teams, etc).

      I suppose the flip answer is that they should all be part of the scrum
      team, but it gets a bit impractical. The skills are too diverse, and
      the teams would be too large.

      Mike
    • Show all 17 messages in this topic