Willy's Reflections

| Willy-Peter Schaub | Visual Studio ALM Rangers | In search of IT simplicity, quality and tranquility |

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

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

Rate This
  • Comments 6

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 :)

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

image

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

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

  1. Where is task 8952?
  2. Why are we missing an hour?
  3. The names Task 2.2.1 and Task 2.2.2 seem in the wrong place, as there is no 2.2 parent.

image

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

image

Finding the other hour

image … 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!

image

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

image

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.

image

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.

image

What was the question again?

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

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

image

Avoiding leaking tasks

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

image

Remembering to action the anomalies

image
  • Casey, the 33 orphaned tasks are yours for vsarDevOps project.
  • Mathias and Willy … oh that’s me … the 18 invalid iteration path items are yours for vsarLabMan and vsarVersionControl projects.
  • Nice post Willy :-)

  • Is deleting TFS workitems recommended? Are you using TFSAdmin Destroywitd "we delete the Tasks 2.2.1 and 2.2.2"?

  • @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.

  • How do you remove work item compared to delete? I thought delete...err...destroywi permanently got rid of them from the database...is there another new way to remove workitems and put them in a recycle bin?

  • @David, simply set the WI state to Removed. If you are happy to remove permanently, use the destroy command.

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

Page 1 of 1 (6 items)
Leave a Comment
  • Please add 2 and 5 and type the answer here:
  • Post