Question

While I love the new FB plugin for VS2010, I find one small detail to be quite the time waster.

Let me start by explaining the way we work...
We're using the backlog plugin, to sort cases according to the logical order they should be implemented. In the VS plugin, we can select to add the backlog column, so that works great.
We can even sort on the Backlog column, so it becomes trivial to just keep popping the next case of the top of the list, implement that, close it, and then just grab the next one on top. Don't need to waste time reconsidering all the active cases, just grab the next one up...

Very efficient!

However, the problem starts when subcases have a backlog, not directly subsequent to the parent case. The primary sort sees the backlog value for the parent case, and orders according to that...

For example, lets say I have:

• parentA, backlog=1
  • caseX (sub of parentA), backlog = 2
  • caseY (also sub of parentA), backlog=4
• caseB, backlog=3

As long as I have caseX open, the sort is good...
But when I close caseX, and now expect that I should next grab caseB, instead parentA is still first in the list, together with it's subcase caseY.
To be clear, even if I close parentA, it will still appear with backlog=blank, and thus be first in the list. Likewise if parentA does not have any backlog value.

---

I think the problem here is twofold:

1. the sorting algorithm puts blank values, first - when in fact it should put it last, or even ignore them completely.
2. The sorting works only at a single level (i.e. parent cases are sorted; subcases are sorted relative only to the parent case). While this is a consequence of the hierachical display (and I'd never give THAT up for the world!), I can't help feel there is a better solution...

Perhaps, in the event the parent case has no value (or even, "gray" case that is only in the filter because it is a parent case), to "elevate" the child case's values in the sort hierarchy. That is, if the parent doesn't count, sort the child case in relation the parent's siblings (even though it is displayed as a child).

Answer 1

You've already identified most of the underlying reasons why you're seeing the behavior you've been seeing, but I just wanted to provide a little more background to hopefully help explain why we decided to have those behaviors.

Most of it boils down to the concept that "hierarchy wins" when it comes to sorting. Showing subcases without their associated parent case(s) in the grid view in FogBugz just felt wrong when we played with it. Part of this often has to do with how subcases are sometimes named (e.g. a subcase's title might not make sense without the additional context of its parent case), and some of this has to do with not wanting the UI to lie to you by obscuring the fact that a case is in fact a subcase.

Another major factor here is how the Project Backlog plugin was intended to be used. It was meant to provide a per-project sorted list, but was never intended to be used across parents and subcases at the same time. Where possible, we've tried to make things work in a way that makes sense when this happens, but as you've discovered, that's not always the case. The logic is that if you've given a parent case a backlog value, that automatically carries down to its subcases.

For example, if you were to have the following backlog:

• Make cake batter (backlog 1)
  • Mix dry ingredients in bowl A (backlog 2)
  • Mix wet ingredients in bowl B (backlog 3)
  • Mix wet and dry ingredients together (backlog 5)
• Preheat oven (backlog 4)
• Bake cake in oven (backlog 6)

While that backlog ordering makes sense (in a way), from a hierarchical perspective it doesn't really. Subtasks of one parent shouldn't depend on anything at a higher level in the hierarchy. Instead, those dependencies should be combined in such a way that only tasks at the same depth have relative orderings:

• Bake a cake
  • Preheat oven (backlog 1)
  • Make cake batter (backlog 2)
    • Mix dry ingredients in bowl A (backlog 3)
    • Mix wet ingredients in bowl B (backlog 4)
    • Mix wet and dry ingredients together (backlog 5)
  • Bake cake in oven (backlog 6)

Or better yet, avoid giving the subtasks backlog orderings at all:

• Bake a cake (backlog 1)
  • Preheat oven
  • Make cake batter
    • Mix dry ingredients in bowl A
    • Mix wet ingredients in bowl B
    • Mix wet and dry ingredients together
  • Bake cake in oven
• Decorate the cake (backlog 2)
• Eat tasty deliciousness (backlog 3)

Obviously this is a very contrived example, and I know it's not always possible to organize things like this, but in general, when I've been using project backlogs and case hierarchies, I try to only give a parent case a backlog value with the implicit logic that all subtasks are completed as part of completing the parent case.

Another place where this "cross-level ordering" problem presents itself is in the grid view when you've sorted your cases by Project Backlog. This results in small up and down arrows in the backlog column that can be used to re-order your backlogged cases, but it doesn't make sense to move a parent case without taking its children with it.

I don't know if this has actually helped clarify anything (sorry it's so long!), but I hope it at least makes the behavior you've been seeing seem a little less bizarre.

Answer 2

I would look at why the cases are subcases to start with. I think the most common use of parent-child relationships is to show that the parent case can't really be considered done until all of its subcases are. If that's true, then putting subcases in the backlog without having them all in order to be completed before the next top-level case after the parent doesn't make sense. If you need to make the batter before you bake the cake, then logically all the subcases of "make the batter" need to be ordered before baking it.

My short answer is that backlog and outline view don't go well together. I show my cases either in flat view by backlog, or outline view sorted by something else.

Answer 3

I've often seen situations where subtasks shouldn't be ordered together, particularly where some of them are not essential. For example, assume the following two tasks, one of which has subtasks:

• Make login screen:
  • Accept and validate username and password
  • Tell user if username or password field is blank
  • Tell user if caps lock key is on
• Provide critical ultra-cool feature

After careful consideration, we've decided that the caps lock warning is great if we can get it in, but we won't hold the release for it, while the other features are all essential. Thus, I'd like for people to work on them in the following order:

• (1) Make login screen:
  • (2) Accept and validate username and password
  • (3) Tell user if username or password field is blank
  • (5) Tell user if caps lock key is on
• (4) Provide critical ultra-cool feature

Note that #4 appears after #5, due to the hierarchy. Unfortunately, I don't have a better answer as to how to display things, but I do want to point out that this other approach to subcases makes a lot of sense for some people.

One approach would be to break the optional subcases out as their own top-level cases (and that's a fine approach for many situations), but that destroys some information I'd like to keep visible.

Frankly, the best solution I can see is the one FogBugz has already taken, which is to have outline view to show hierarchy and flat view to ignore it. It's not perfect, but I can't offer any better ideas.-