The hunt for stealth tasks … what happened to my task on the TFS task board?

In one of our project stand-up meetings the ruck master DREDD and project lead STAR (see Practical Ruck Guide for info on these personas) of team PUZZLED were puzzled as they discussed the backlog looking and were desperately looking for missing tasks and pondering over other tasks who’s title were confusing within their context. Note that names of personas and team have been changed 🙂

Let us investigate and ensure we can avoid similar moments of “huh?” and waking up in a cold sweat worrying that you have lost (misplaced) tasks on the backlog.

Starting with 13 hours of work

After a brief discussion with DREDD and STAR, we defined a simple backlog of three product backlog items and seven tasks, with a total of 13 (my lucky number) remaining work hours.

We used numbering to emphasise flow and ownership, i.e. Tasks 2.2.1 and Tasks 2.2.2 are children of Task 2.2.

Yes, we can see a few raised eyebrows, keyboards and hands … the use of a task (8952) as a parent of other tasks (8953 and 8954) is not the typical way we break-up the backlog … but it is the way team PUZZLED decided to do it.

Tracking 12 (13-1) hours of work

When we switch to the task board for the given sprint we should realise why DREDD and STAR were puzzled.

Where is task 8952?

Why are we missing an hour?

The names Task 2.2.1 and Task 2.2.2 seem in the wrong place, as there is no 2.2 parent.

Switching to the Task Backlog view we see the same anomaly … we have a stealth or missing task.

Finding the other hour

… finding the stealth task requires us to use the overall backlog list, with tasks showing.

Voila, Task 2.2 and the 13th hour is back!

Alternatively we can use the query we created in Visual Studio Team Explorer, which shows us the complete backlog.

What happens when we close / remove child tasks?

As part of our research we decided to close the child tasks of Task 2.2.

Other than the tasks moving into the correct DONE column, we see no change.

If, however, we delete the Tasks 2.2.1 and 2.2.2, Task 2.2 comes out of stealth mode and lights up on the task board.

What was the question again?

Before we forget, let’s summarise the core question(s) and the answer.

Question

Where are my parent tasks? Why are they not showing?

Answer

The task board only show leaf nodes. This is by design.

The outcome of our analysis and this blog post is to discourage the use of tasks as containers of tasks.

Use a product backlog item (PBI) to act as a task container, and use define special task dependencies.

Avoiding leaking tasks

We also created queries, which we pinned to the team page, to light up other anomalies. Visibility is key!

Orphaned Tasks … shows all tasks that have been forgotten, left-behind or assigned to sprints in the past.

Invalid Iteration Path … shows all tasks that are not assigned to a sprint. In some cases this query will raise false alarms, for example when a team has pro-actively broken its backlog into detailed tasks, but has not assigned them to sprints yet.

Invalid Area Path … shows all tasks that are not assigned to an area. These are in essence team-less tasks and will probably end up being neglected.

@David, whether deleting WITs is a good thing depends on the context. If there is no dependency on the work items they can be deleted using the TFSAdmin utility. In the above post we merely deleted, or rather removed, work items to investigate the behaviour.

I'm trying to set up my team to use all of this Agile stuff with the boards. It looks like a nice work of getting the whole view together. However, at the moment, we work off tasks and it works really well. What we're missing is the visual overview and display for management as to what is getting done in the next release – which TFS should work well with.

In this system, we have to add a PBI to create a task. A task might then have a bug so we create that, then add a task to the bug. A lot of our tasks are little updates so it ends up being a mess of 1 to 1 mapping.

One solution was to add a "Bug Task". A copy of my task (with custom states), renamed, added a severity and coloured Red on the board. I thought this was going to be perfect until this "by design feature". Back to the drawing board.

Thanks for this!
We’ve also encountered some unexpected behaviour that I’d like to outline somewhere. This blog is the lucky target 🙂
You have a PBI, planned for sprint 1, with tasks that are done and others that aren’t. The end of the sprint is near and you decide to push the entire PBI to sprint 2 as it isn’t gonna get done.
As expected, you will see your PBI in Sprint 1’s task board only showing the done tasks.
And in Sprint 2 you will see the same PBI, only showing the not-done tasks.

So far so good.

But when you mark a task from Sprint 2 as Done it will dissappear on page refresh and suddenly be back under the PBI in Sprint 1.
So, it kind of disappeared.

I’m not sure if this is expected behavior but it has been confusing us bigtime.
Hope it helps someone.