You can’t stack rank hierarchical work items?

Audience

Everyone

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?

image
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?

    image
    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”?

    image
    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.

image
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.

image
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.

image
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.

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

    image
    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.

    image
    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.

    image
    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.

image
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?

Create a conversation around this article

Share on Facebook
Share on Twitter
Share on Linkdin

Read more

Martin Hinshelwood
The Boards in Azure DevOps are a powerful tool that your teams can leverage to enable transparent visualization of the current state of value delivery.  However, the inclusion of Blocked columns can stealthily erode the very foundations of efficiency these boards are meant to uphold. By obfuscating the state of …
Martin Hinshelwood
This week, I participated in a Scrum.org Webinar hosted by Sabrina Love (Scrum.org Product Owner) as well as my colleagues, Joanna Płaskonka, Ph.D. and Alex Ballarin 🇺🇦 to discuss the state of learning and how immersive learning is the future of training. You can watch the video below to hear …
Martin Hinshelwood
Business Leaders face a key challenge when scaling their organisations effectively while maintaining the distinctiveness that made us successful in the first place. Many frameworks and methodologies, such as Scaled Agile Framework (SAFe) or the Spotify Model, promise a structured approach to scaling, but do they genuinely fit our unique …
Martin Hinshelwood
As we inch further into the dynamic landscape of the 21st century, our long-established Alpha organisations stand on shaky ground. The organisations whose DNA is infused with strict command and control, woven into the fabric of every process, are feeling the tremors of a rapidly evolving, technologically charged market. Not …