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

RE: [scrumdevelopment] Re: Product backlog preparation

Expand Messages
  • Schiel James - SHS Malvern
    Tim, this is a hot topic for me as well. I think Horst is on the right track here. When we organize our product backlogs along pre-existing teams, we re making
    Message 1 of 6 , Feb 14, 2005
    • 0 Attachment
      Tim, this is a hot topic for me as well. I think Horst is on the right track
      here. When we organize our product backlogs along pre-existing teams, we're
      making the assumption that the team structure as it currently exists just
      happens to be right for the next round of features (product backlog items)
      as well. While that may be the case, the odds are against it. True, we tend
      to make the assumption that specific team structures will work over the long
      haul, but then we re-organize on a regular basis anyway.

      The approach that we're looking at taking revolves around understanding the
      product backlog from a release planning (priority) perspective and then
      staffing the teams as needed to complete the release. This type of
      malleability of resource is difficult to achieve, but it is manageable over


      -----Original Message-----
      From: Horst Franzke [mailto:h.franzke@...]
      Sent: Sunday, February 06, 2005 11:50 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: Product backlog preparation

      Hello Tim,

      maybe I got kind of confused by your questions(s), but this is what I

      Your are migrating an existing project team, which was setup to build
      a huge system. Before getting to your specific question: what are your
      limitations to restructure the team and get towards "feature teams"?

      Amongst others there seems to be a specific problem with large teams
      within a large organization: the team structure reflects the
      organization's structure and even more: the system's architecture
      reflects the organization's structure, too (Conway's Law).

      Don't get me wrong, but I ask myself: is the problem of the complex
      Product Backlog just the consequence of some underlying problem (i.e.
      team structure, or even size at all)?

      (by the way: "Agile Software Development in the Large" by Jutta
      Eckstein, www.jeckstein.com, provides lots of good thoughts about
      large software development teams)

      Kind Regards,

      --- In scrumdevelopment@yahoogroups.com, "Hagemann Tim (extern) Com MD
      PD SWC 22 KLF" <tim.hagemann.ext@s...> wrote:
      > Hi Scrum-Experts,
      > I got another hot question here for you coming up when we discussed
      a migration from our traditional principles towards some more agile
      > The product backlog keeps the already known features or requirements
      for the product/project. Each feature has an associated priority (in
      our case: business value) and some kind of effort (for example feature
      or function points).
      > Because we are working on a huge system with several teams, we need
      a type of decomposition to allocate sub-features to the specific
      teams. This decomposition and of course the needed effort estimation
      has to be done before the sprint planning meeting takes place (at
      least in our opinion).
      > But we can not do this for every product item in the sprint planning
      meeting itself because:
      > - we have to split the features across the specific teams
      > - we have to estimate
      > Both things may take some time - more than available in a 4h time
      box.So before starting the sprint we have some upfront work, at least
      for creating a product backlog list for the meeting.
      > On of our idea was to create a small upfront mini process to prepare
      the effort and business values for the product backlog as well as the
      needed decomposition. But we don't like this idea because it generates
      a) upfront work and b) waste, if the items are removed from the
      backlog without being realized...
      > Any suggestions / best practices?
      > Best regards,
      > Tim.
      > ---------------------------------------
      > Tim Hagemann
      > Siemens AG
      > ICM MP PD SW 22 KLF 1
      > phone 0049 (2842) 95 - 8746
      > mobile 0049 (170) 815 8294 (new!)
      > mail Tim.Hagemann.ext@s...

      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:
      Yahoo! Groups Links

      This message and any included attachments are from Siemens Medical Solutions
      USA, Inc. and are intended only for the addressee(s).
      The information contained herein may include trade secrets or privileged or
      otherwise confidential information. Unauthorized review, forwarding, printing,
      copying, distributing, or using such information is strictly prohibited and may
      be unlawful. If you received this message in error, or have reason to believe
      you are not authorized to receive it, please promptly delete this message and
      notify the sender by e-mail with a copy to Central.SecurityOffice@...

      Thank you
    Your message has been successfully submitted and would be delivered to recipients shortly.