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.
 |
|
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
… as part of our dog-fooding environment (ALM Rangers dogfooding journal of the Team Foundation Service) we typically avoid the use of task as a container of more 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.
Remembering to action the anomalies
 |
|