RE: [scrumdevelopment] Re: Product backlog preparation
- 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
From: Horst Franzke [mailto:h.franzke@...]
Sent: Sunday, February 06, 2005 11:50 AM
Subject: [scrumdevelopment] Re: Product backlog preparation
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)
--- In firstname.lastname@example.org, "Hagemann Tim (extern) Com MD
PD SWC 22 KLF" <tim.hagemann.ext@s...> wrote:
> Hi Scrum-Experts,a migration from our traditional principles towards some more agile
> I got another hot question here for you coming up when we discussed
>for the product/project. Each feature has an associated priority (in
> The product backlog keeps the already known features or requirements
our case: business value) and some kind of effort (for example feature
or function points).
>a type of decomposition to allocate sub-features to the specific
> Because we are working on a huge system with several teams, we need
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).
>meeting itself because:
> But we can not do this for every product item in the sprint planning
> - we have to split the features across the specific teamsbox.So before starting the sprint we have some upfront work, at least
> - we have to estimate
> Both things may take some time - more than available in a 4h time
for creating a product backlog list for the meeting.
>the effort and business values for the product backlog as well as the
> On of our idea was to create a small upfront mini process to prepare
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...
>To Post a message, send it to: scrumdevelopment@...
> Any suggestions / best practices?
> Best regards,
> 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 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@...