Subscribe to our blog by signing up for the naked Agility newsletter, or by subscribing to the RSS feed.

You can’t stack rank hierarchical work items?

At the MVP Summit I was appalled by the number of people who asked questions about new features for supporting hierarchical tasks! I shared a disgusted look with Peter Provost and we had a quick (and I mean really quick) conversation that resulted in this post. it really comes down to one thing:

You can’t stack rank hierarchical work items?

If you want to continue to be competitive in the world of modern software development you need to be able to effectively order (stack rank) a list of well understood items. This could be at the PBI (or Product Backlog) level or it could be at the Task (or Sprint Backlog) level but I need to be able to do that ordering by moving things about… how do I do that with a tree?

Figure: How do you order a tree?

No really! Lets look at a couple of specific questions:

  • What do you expect to happen when you reorder “PBI 3” above?

    Figure: If you said they all move then you get a prize

This has to be the expected out come because of that pesky parent / child relationship.

  • What would you expect to happen when you drag “PBI 8” to be between “PBI 1”  and “PBI 2”?

    Figure: Was that what you expected?

    If you said that it would move to the right location then you also get a prise, but what do you think happened to the parent relationship with “PBI 3”? Thats right, it was removed as that item can no longer exist as a child or “PBI 3”…

    Note: You can keep the relationship by creating it as a “related” relationship, or you could add a custom one.


So what is the expected behaviour when you discover a PBI that is too large (for whatever reason) and you want to break it down into two smaller ones. Once you have broken a PBI down into two smaller ones that encompass all of the things we need to make the larger one what purpous does it solve… have we not just replaced it? Well then, lets remove it.

Figure: Good example, Mark the parent story as removed

This only makes sense as I have all of the relevant information in the two new PBI’s.

Figure: Now I have no “PBI 3”

If I look at the history for that “removed” PBI I can, and I will, be able to see all of the history including that the links to the children still exist. This means that you can still query and see what those relationships were without them interfering with the backlog any more.

Figure: I can still have my tractability

Let me jus say that I am not suggesting that you do not use linking, there are many links that are and should be available. Which of those links are good to use,  provide value and make sense  for both the team and your product owners:

  1. Tasks with a Parent / Child relationship with a PBI

    You need for your team to be able to keep track of the work that they are doing to achieve a single PBI and this is that. There are other options, but this is the best one.

    Figure: Good example, You can have Task as a child of

    Figure: Bad example, do not use PBI’s as children of other PBI’s

  • Test Cases with a Tests / Tested By relationship with a PBI

    You want to be able to trace from code to requirements to bugs all with the relevant tests that make sure that we built the correct thing.

    Figure: Good example, You can show what your PBI is Tested By

  • Bugs that have a Tests / Tested By

    I would expect this to be a no-brainer as you can’t have a bug unless you can prove that it exists. Bugs have “steps to reproduce2 after all and in the post MTM world this is the result of a failing Test Case.

    Figure: Good example, Bugs have test Cases too


I a using the Visual Studio Scrum 2.0 template (default) so while you can make things more complicated, this is about as complex and the expected common cause use cases go with Work Items. There are other artefacts links to support things like Test Results, Code Reviews, Feedback Results and others, but they are tool bits not really that user configurable.

Figure: Bad example, nesting Work Items is very unwieldy

I am always interested in finding out what other scenarios there are out there:

Do you agree?

What reasons do you have for using hierarchy’s?

  • Good post Martin.

    I think the biggest reason people want hierarchical work items it out of a desire to establish a relationship between PBIs or User Stories and more meaningful business elements like Experiences and Features. When the boss asks “When will that feature be done?” (s)he is really asking a question about how the team is doing on the collection of stories that comprise that feature.

    David Starr and I have discussed this quite a bit and we’ve come to the conclusion that there is clearly a relationship between a story and one of these higher level business items, but it is NOT a parent-child relationship!! It is just a “relates to” relationship. This is even more clear when you realize that in fact a single PBI or User Story can contribute to multiple Experiences or Features. This many:many relationship clearly shows that it is not a hierarchical relationship.

    Adding parent-child hierarchies is a reasonable ask when you first look at it, but it clearly doesn’t work out, as you show above.

    Now as for why people would even want hierarchical tasks, I have no idea at all.

  • Kym Phillpotts

    Yup, good post Martin.

    I completely agree with you what you have to say in this post.  

    In our development environment (using TFS2010) I strongly discourage use of Nested Stories.   For all of the reasons you specify in this post.  Also (especially in TFS2010) it just makes the backlog harder to read and understand.  I encourage our team to have basically two levels for everything.   A user story and underneath that a collection of Tasks.

    When you think about it, if you are nesting User Stories in TFS you are pretty much just breaking best practices for User Stories, you have broken the I in INVEST.  In other words, you are indicating they are not INDEPENDENT.  You are probably breaking the S as in SMALL as well 🙂

    I encourage trying to keep the backog as simple as possible, makes it so much easier to report on and understand.


  • Martin,

    Nice post that definitely makes sense for lots of projects.
    We make use of hierarchical work items to relate our work to meaningful business elements, and we make use of sorting, but we don’t want to sort the hierarchy 😉

    At our company we make use hierarchical items on the Product Backlog. We distinguish between a Theme, Epic, Feature and Story. Themes are about investments (in euros of manmonths), Epics are about more or less (making product delivery faster or inventory cheaper), Features are about how Epics will be supported by (automated) tools and Stories are about chunks of functionality that can be built by the Team in Sprints.
    Themes and Epics are for reasoning about upcoming and current releases (the portfolio level), Features and Stories are for reasoning about delivering value by supporting the business (the project level).

    We definitely like to put our Themes, Epics, Features and Stories in a hierarchy as it is an intuitive way to show them and discuss them with the team and with stakeholders. We try to keep is simple, so we allow for a tree (one to many), but not for a forest (many to many)
    The hierarchy also helps us in situations where we need traceability, i.g. from the investment to handle a business risk to the delivered functionality lowering that risk. Or from a company wide architectural decision (an Epic) to the functionalilty built do support that decision.

    At our company, Stories should be Ready, for us that means INVEST and small enough for a Team to deliver during a sprint. Stories are ranked. The top ranked stories should be delivered as soon as possible. So when we decide upon what to do in the next sprint, we query our product backlog for Product Backlog Items of type “Story” and state “Ready” ordered by Stack Rank. This query is a simple flat list and normally does not contain more than twenty stories. More is too much work in progress (WIP). These stories can literally come from everywhere in the hierarchy, as it is common that part of an important Feature can be postponed to be delivered at a later moment.

    Of course, our stakeholders also want insight into our project to find out whether the changes they requested will make it on time. Therefor we query our product backlog for  for Product Backlog Items of type “Story” and state “New” and “Preparing”.

    This query is also a simple flat list and can normally contain more than a hundred stories. Some big, some small, most of them not yet INVEST. All stories have an estimated number of story points. Based on the velocity of the team (in story points) we can easyly indicate for every story how many sprints it will take before that story will be implemented.

    During the sprint, the team should be working on the stories with the highest priority. This gives reason for a third query. We query our product backlog for Product Backlog Items of type “Story” and state “In Sprint” ordered by Stack Rank. It is an hierarchical query showing the stories with underlying Tasks (sprint backlog), Defects and Impediments.

    To summarize: our Product Backlog is sorted (one hierarchical and two flat list queries for three different reasons) on Stack Rank.

    Our product backlog hierarchy is also sorted, as there is always some reason one Epic should be shown before another. We do not use the Stack Rank attribute for this purpose, but use an extra attribute (Rank) for that purpose. The order used here is for presentation purpouses and is mostly along a timescale or along the steps of a business process. It has less to do with ordering on business value for which we use the Stack Rank.

    Using a different attribute (Rank vs Stack Rank) helps to make sure ordering in one dimension does not interfere with the ordering in another dimension.

    Harry Nieboer
    Info Support

  • Rajko

    Hi Martin, good post so far but tell me how do you handle feature enhancements? In our case, we use the hierarchy to show which functions our modules have. If we for example want to enhance a feature with a new functionality, we add it as linked pbi to the existing one, same thing with bugs. If a PBI (feature) doesn’t work, we link a bug as child. Thanks in advance.

    • 1) It is ok to take the understanding of the hierarchy into account when you are stack raking, but you can only physically stack rank a flat list. If you are on Team Foundation Server 2013 you get separate Feature and Backlog Item backlogs where you can stack rank ( each separately with knowledge of each other.

      2) It sounds like you are on one of the MSF process templates. While they are ‘agile’ implementations of MSF, I would not consider them agile. In MSF the bugs are treated separately so as not to burden the customer with all of the bugs you as a consulting company are adding to the system. We will keep them separate and hidden. In the Scrum template( the only agile one in TFS) bugs are backlog items that are stack ranked like any other. As the template inhibits the businesses ability to prioritize effectively I would recommend moving to the Scrum template ( which will set you in better stead.

      Ultimately if you are looking at a flat list and ordering that list you will be OK regardless of the meta data that you use to make ordering decisions.

  • David V. Corbin

    I am middle of the road here. While I agree with the limitations, there is also the matter encapsulation and abstraction. One Work Item may be atomic when looked at as part of a flat list, but internally have multiple parts that have no meaning outside of the context of the parent. The examples about moving items are all compatible with this. A child must move with the parent (no emancipated minors)….

    The problem (From my perspective) is when one is looking at the children SOLELY within the context of the parent. There is definite utility to being able to order these within that context.
    Unfortunately, it is not there.