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

25586RE: [scrumdevelopment] Re: Single backlog per team

Expand Messages
  • Roy Morien
    Dec 2, 2007
    • 0 Attachment
      Given that a 'project' is really just a collection of apparently associated activities, probably intending to achieve a common outcome, then I think that is what should be in the Product Backlog. If there are other activities that have no relevant association, then perhaps they should be in another Product Backlog.
      I think one major influence on this is to do with the changeover effort and setup time needed for team members to move from one activity to another. It is clearly inefficient and wasteful if the team is moved to something else that has no relevance to what they are currently doing. Perhaps this is the benchmark that you should apply to deciding your 'projects' and the associated Product Backlog.
      Of course, for those teams that are predominantly doing maintenance and 'on request' type development, where service requests come in almost on adhoc or asynchronous basis, then there may be no escaping the need for such changeover and setup times, and everything goes into a common Product Backlog.
      But in all of this, common sense must prevail, surely. If it is convenient and efficient to have many teams, each with its own PB, then fine, go for it. Each PB will have to be separately prioritised. If a common backlog that is shared by many teams, then that implies that many teams, of appropriate numbers each (7-9 maximum) share the same PB, and then it just becomes a problem of handling the prioritising of the PB, AND of the orderly selecting of items to go onto the various Sprint Backlogs.
      Yes?  No?
      Roy Morien.

      To: scrumdevelopment@yahoogroups.com
      From: yi.xu@...
      Date: Mon, 3 Dec 2007 05:46:20 +0000
      Subject: [scrumdevelopment] Re: Single backlog per team

      Hi Gilad,

      I think your "backlog" means "product backlog", right?

      Then I against the idea of having a single product backlog per team.
      First, product owner is the person who can decide the format of
      product backlog. And basically I think you do not have a single
      product owner for different projects. Second, the product backlog is
      constructing based on priority, how you construct the product backlog
      among projects? Then you mess up the backlog with project priority,
      which not directly relate to customer requirement priority.

      Based on the assumption you have to work on different projects in
      same sprint, my suggestion is :

      You should have your team's capacity estimated, then perhaps you need
      to negotiate with project managers about capacity division among
      projects. Then use your project specific capacity to select product
      backlog items for different projects.

      Best Regards,
      Xu Yi-Kaveri

      --- In scrumdevelopment@ yahoogroups. com, "gzgruber"
      <gilad.gruber@ ...> wrote:
      > Mates,
      > Our teams sometimes have multiple projects. I am wondering what is
      > best way and what is the SCRUM way of handling this. My feeling is
      > the best way is to have a single backlog per team (even if this
      > that in a sprint the team is working on backlog items belonging to
      > multiple projects). I think the purists will recommend splitting
      > team and having multiple backlogs.
      > Any thoughts on this would be greatly appreciated
      > BR,
      > Gilad

      Check our comprehensive Salary Centre Overpaid or Underpaid?
    • Show all 10 messages in this topic