It's all about the answers!

Ask a question

Product Backlog: a potential for improvement?!


Taha Boulaguigue (1899) | asked Mar 12 '11, 7:59 a.m.
In a scrum project the Product Backlog is the list of prioritized requirements.
The product owner uses the list for regular discussions and reviews with the customer(s). In RTC when the scrum master assigns stories to a Release or Sprint Backlog the stories are moved from the Product Backlog to the Release/Sprint Backlog. This could be quite confusing for the product owner who needs to use several plans to recap the status of the product backlog. It would be helpful if the assigned stories are still showing in the Product Backlog Plan.

One answer



permanent link
Ralph Schoon (63.1k33646) | answered Mar 21 '11, 5:12 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Taha,

I might not get the full issue here, however I think RTC provides you with what you desire. It is just a matter of setting it up in a way that is convenient to your usage model.

There are different plan types that select different work items and that can be used to achive what you want. Please see also http://jazz.net/library/article/589 and there are also several interesting articles about planning in the library.

The RTC 3.0 Scrum template has a timeline with a release as the root iteration. A Release Backlog Plan type configured for this iteration will, by default, select all top level work items across all enclosed iterations. It allows filtering for teams and iterations also. To see all work items associated to this iteration hierarchy, select the advanced option "Always load all execution items" in the plan configuration.

The backlog iteration is anther parallel root. This is supposed to contain all work items that are not scheduled for any other iteration. A product backlog is created if you create a plan for this iteration.

If you would like to have them in the release backlog you could just move the backlog iteration into the release hierarchy. Then this iteration would appear in plans that select it and you could see all data on one plan and rank it.

You might want to consider setting up the timeline with a little bit different structure to get all advantages. Here is an example

Timeline Ti
*Iteration PR (Product)
** Iteration R1 (Release)
*** Sprint 1 (R1)
*** Sprint 2 (R1)
** Iteration R2 (Release)
*** S1 (R2)
*** S2 (R2)
** Iteration Backlog

A Product or Release Backlog plan configured for the project and the PR iteration would show you all work items you are interested in. The same plan type configured for R1 would only show work items considered in Release 1 etc.

I think it is just a matter of partition the data in a way that really allows to be most effective. The default keeps data off the plan that is yet not considered to be implemented at all.

Ralph

In a scrum project the Product Backlog is the list of prioritized requirements.
The product owner uses the list for regular discussions and reviews with the customer(s). In RTC when the scrum master assigns stories to a Release or Sprint Backlog the stories are moved from the Product Backlog to the Release/Sprint Backlog. This could be quite confusing for the product owner who needs to use several plans to recap the status of the product backlog. It would be helpful if the assigned stories are still showing in the Product Backlog 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.