It's all about the answers!

Ask a question

Relationship between a "Product Backlog" and a "Release Backlog" in RTC?


Jeffrey Neau (11112313) | asked Jun 20 '13, 11:50 a.m.
What is the suggested relationship between a Product Backlog and a Release Backlog in RTC?

One option I see is to have the Product Backlog and all the Release Backlogs (for each release) be peers, and then have the Sprint Backlogs be children of the Release Backlogs:
  • Product Backlog
  • Release 1 Backlog
    • Sprint 1
    • Sprint X
  • Release 2 Backlog
    • Sprint X+1
Another option is to have the Product Backlog be the parent of everything:
  • Product Backlog
    • Release 1 Backlog
      • Sprint 1
      • Sprint X
    • Release 2 Backlog
      • Sprint X+1
What do people do in practice?

3 answers



permanent link
Chris Newton (3036) | answered Jul 01 '14, 11:31 a.m.
Our organization has always kept the product backlog separate from the development timelines (containing the releases and sprints). As Millard points out, that extra level in the hierarchy just makes it a little more challenging to navigate.

permanent link
Radha Sastrigal (111122) | answered Jul 01 '14, 9:46 a.m.
 Hi Millard,

Based on your response, do you think the following heirarchy would be easier to work with:
Product Backlog - Application Release Plan
Release Backlog - Iteration 1
Sprint Backlog - Build 1.1
Sprint Backlog - Build 1.2
Sprint Backlog - Build 1.3
Release Backlog - Iteration 2
Sprint Backlog - Build 2.1
Sprint Backlog - Build 2.2
Sprint Backlog - Build 2.3

Is there any limit on how many plans of type Release backlog and Sprint backlogs are created within a Parent Product backlog?
Please advise


permanent link
Millard Ellingsworth (2.5k12431) | answered Jun 20 '13, 4:13 p.m.
FORUM ADMINISTRATOR / JAZZ DEVELOPER
The hierarchical relationship between a release backlog and sprint backlog is caused by the iteration configuration in your timeline (by making sprint iterations children of the release iteration). Each timeline can have one Backlog iteration (that would normally be associated with the Product Backlog). 

I can't think of any advantages to making the Product Backlog a parent iteration. By associating it with the timeline as the defined Backlog iteration, it gets some special status. Adding it to the iteration hierarchy probably just crufts things up (you'll have more layers to navigate when picking an iteration, for example). It may also cause issues with roll-up displays in the plans -- you may now see roll-ups into the Product Backlog, which is not its purpose and may make it harder to work with.


Comments
Robert Wen commented Jul 01 '14, 10:48 a.m.

One other consideration, especially if you're using plans is that the plan loads information about the child iterations (whether it needs it or not) in the background.  Making the product backlog the parent iteration of all releases could impact performance when viewing the plan. 

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.