3

We use TFS 2013 with the Scrum 2013.4 template. We have one single project defined in a single collection. This project contains all the backlog items for all different subsystems and their features. To manage this backlog, we us the Portfolio Management approach.

With witadmin.exe we created another category (backlog level), as explained in this article on MSDN about Portfolio Management, under the "Add another backlog level"-section. Only instead of "Initiative", our new category is called "Subsystem". Everything is showing up fine in TFS.

We can now categorize backlog items like this:

MainProject

--->Subsystem

------>Feature

--------->Backlog Item / Bug

------------>Task

All works fine, including different views on the backlog, where all the relations are visible (like subsystems to features, subsystems to backlogitems, backlogitems to tasks, etc.).

The problem is that if we select the backlog of the current sprint (or any other sprint), it shows only backlogitems and tasks, so it is unclear to which feature or subsystem the backlogitem belongs.

Is there a way to change the default query or output, so that the Sprint Backlog will also show the Features and Subsystems in addition to the backlog items?

Jeroen1984
  • 1,616
  • 1
  • 19
  • 32

1 Answers1

4

There is not.

Things in the backlog are part of the time limited execution flow and that does not represent sub system well.

You would be better adding a picklist to PBI, bug, and feature that had a list of sub systems. You would them be able to see on the item where it was for.

I usually reflect sub system in the area path and move team to a separate field.

http://nakedalm.com/team-foundation-server-2012-teams-without-areas/

MrHinsh - Martin Hinshelwood
  • 23,409
  • 5
  • 46
  • 69
  • Thank you for your answer. The thing is, we don't have multiple teams since we have a very small development division. So the team needs to work on all subsystems / features / PBI's. For that reason i think areas are a little bit overkill. I'll have a look at the picklist-idea... – Jeroen1984 Apr 22 '15 at 06:28
  • Areas are the correct and recommended approach for what you describe. Customising the work item hierarchy is overkill and should be avoided. – MrHinsh - Martin Hinshelwood Apr 22 '15 at 06:41
  • But what exactly are the benefits of using area's, when we have only a single team? And how are area's going to solve my original problem (backlog items and tasks showing up in the sprint backlog as one big list, without the ability to see which feature or subsytem it belongs? – Jeroen1984 Apr 22 '15 at 08:26
  • I would also like to say that your blog posts on nakedalm.com helped us a lot in basic understanding of managing work in TFS. Actualy, the posts about using a single project instead of multiple projects in TFS has inspired me to reorganise things this way. The only thing i can't seem to get is that big list of PBI's on the sprint backlog. If i could only see to which feature those PBI's belong, just like in the Product Backlog when turning the features view on.... – Jeroen1984 Apr 22 '15 at 08:47
  • 1) Area can be used to break down your product into components so that you can report independently – MrHinsh - Martin Hinshelwood Apr 22 '15 at 19:14
  • 2) if you go to the backlog and turn on committed with you can see the features. – MrHinsh - Martin Hinshelwood Apr 22 '15 at 19:15