It's all about the answers!

Ask a question

Program Roadmap: Backlog part of it OR not?

Olivier Béghain (1081933) | asked Jun 21 '17, 9:40 a.m.

Hi Guys,

I'm using the Safe program RTC template and I have a doubt on the way I'm considering the relationship between the program backlog concept and the Program Roadmap concept. 

Until now (independently of the tools), I considered that the content of the program backlog was "outside" of the scope of the program roadmap (in RTC terms, outside range of a given plan focussing on the "roadmap" timeline node). As such my program roadmap starts with the timeline node just above the different PIs; the program backlog being a sibling timeline node of that PI-parent node, the program backlog is "out-of-scope" of the roadmap's view.

Looking at the default RTC timeline setup, I see that the backlog is set after the Pis (normal) but also is a child under the roadmap timeline node. Does this imply that the right interpretation to be given to a program roadmap is that it embeds the program backlog? 


Accepted answer

permanent link
Amy Silberbauer (30657) | answered Jun 21 '17, 11:16 a.m.

This is a great question. The reason we did it this way was so that, when you create a Roadmap plan view, you can include in that scope the Backlog items so that you can actively plan within that plan view. For example, you may want to see things on the Backlog and move them onto an iteration on the Roadmap. If you have the Backlog iteration outside of the Roadmap iteration, you would need two separate plan views, so it is partly a convenience.

That said, consider that artifacts sit on the Backlog until they are ready to be "pulled" for implementation. It is not necessarily that they aren't part of the Roadmap. So, a Feature may be Approved and waiting for implementation, but planned for the Backlog because it is not yet in a committed plan. You might consider also using the Proposed iteration to put artifacts on the Roadmap somewhere but leave Planned For = Backlog until you are going to work on something.


Olivier Béghain selected this answer as the correct answer

Olivier Béghain commented Jun 22 '17, 2:15 a.m. | edited Jun 22 '17, 2:16 a.m.

Thanks Amy for the prompt reply.

I understand the usability consideration that led to this design and can even live with it  to explain it :-)
I also thought to use the Proposed For as a way to indicate in which PI (that is still on the backlog) might have to be consider for. Now, I am assuming that within a plan view where work items are grouped by iterations, the value of the Proposed For field won't be considered. Right?


Amy Silberbauer commented Jun 22 '17, 8:49 a.m.

That's correct, if you group by iteration, that function is using the Planned For field by default and by design.

Your answer

Register or to post your answer.