I'd like to validate I'm not in the wrong way.

My team project is using Visual Studio Scrum 2.x. Since each area/product has a lot of kind of requirements (security, user interface, HTTP/REST services...), I tried to manage this creating "parent backlogs" which are "open forever" and they contain generic requirements.

Those parent backlogs have other "open forever" backlogs, and/or sprint backlogs.

For example:

  • HTTP/REST Services (forever)
    • Profiles API (forever) *POST profile (forever)
      • We need a basic HTTP/REST profiles' API to register new user profiles (sprint backlog)

Is it the right way of organizing the product backlog?

Note: I know there're different points of view and that would be right for some and wrong for others. I'm looking for validation about if this is a possible good practice on TFS with Visual Studio Scrum.

  • If the items are open forever, they are never really worked off. They are probably not prioritized against each other. So I don't see that they would belong in a backlog. I like Patrick's use of a hierarchical backlog below. Commented Nov 9, 2014 at 2:33
  • @M.K.Hunter Well, really this was a thought some time ago and I arrived to the conclusion of using areas to hierarchically organize the whole backlog Commented Nov 9, 2014 at 9:45

2 Answers 2


As far as I understood hierarchical backlogs: They are not meant to be organized by technical topics, but rather organized by abstraction level of the work item. The lowest levels are supposed to be the most technical, the highest the most business-value/business-goal related.

In the MSDN documentation there is an example with the following hierarchy:

  • World-class customer support
    • Mitigate impact of low-coverage areas
      • Data cache improvements

To me this way of using the different levels seems to be useful for:

  • Capturing high-level goals - even if they are currently out of scope for development and without having to specify technical, detailed tasks
  • Documenting the presumed link between the technical detail and the expected business outcome
  • The the similar abstraction levels within each level and the context of the upper layers provide a good framework to discuss alternatives or prioritization
  • Does each level of the backlog have a priority, and does that inform the lower-level priorities? Commented Nov 9, 2014 at 2:33

The idea of having a "bucket" backlog is something my organization started with but moved away from. We resolved this problem by moving to Area Paths by module. For example, we have a Web Services, Web Interface, and Data Access area path for one of our team projects.

You could also consider using TFS 2013's Initiative and Feature work items, but as far as I know those are intended to be finite work items as well.

  • 4
    This would be a better answer if you explained why you moved away from the bucket backlog, and how Area Paths improved things. Commented May 3, 2014 at 19:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.