651.288.7000 info@intertech.com

(Note: This post makes heavy use of links to official documentation to allow users new to TFS to investigate the concept via official documentation and yet keep this article on-point of communicating information not readily apparent by reading that documentation).  

One of the ballyhooed features of Team Foundation Server 2015 is that individual teams in a team project (regardless of the process template their team project was configured to use and without customizing the process template) can now configure for themselves how/where they want to manage bug work items in one of 3 ways:

1. Have bugs appear on the team’s backlog and assigned to iterations along with their process template’s requirement-level work items.  (This option has been the out-of-box behavior for those team projects configured using the Scrum or CMMI process template.)

2. Have bugs appear on the task board alongside of the task-level work items which are tracked as a part of what needs to be done for a requirement to be called “Done.”  These will also appear in the team’s backlog as child work items under the requirement to which they are attached.  (This option is new.)

3. Have bugs managed separately through work item queries rather than clutter their backlog or task board with that detail.  (This option is the out-of-box option for team project’s configured to use the MSF-Agile process template.)


My ranking and rationale for this feature:  

(See half-way down my last blog article for the ranking system I’m using.)

OKOK for TFS Cloud/Visual Studio Online users.  I rank this option in my “OK” category because at least VSOnline teams can now configure this behavior regardless of the process template chosen at team project creation time.  However, in practice it has some friction points for some process templates more than others, and does not go far enough to give teams the option of managing bugs at both the task and backlog level as expounded on below.

YawnMostly yawn for on-premise TFS shops, because since the 2012 release they have always had this ability to add bugs to the backlog and task board through a well-documented customization path — though making this a choice at the team level is new.  However, this team-level choice isn’t what makes this enhancement not a total yawner since teams can easily make the choice not to manage bugs at one level or another by just not doing it.  There is now a more friction-free experience for testers who want to create task board level bugs as expounded on below..

Understanding the process template choice as a background to this feature:

As a background to my review of this feature, it is important to understand the TFS notion of what it means to choose a process template when you create a team project.  For those reading this blog very familiar with the information and process differences the various process template choices give you when you create a team project, jump to the section below entitled “Agile tooling, your process template choice and customization.” For others new to TFS, here’s the condensed summary of what is affected by this choice which can be difficult to grasp, even though the MSDN help has made great strides at least in helping to explain this.

When you create a team project in TFS, you have out-of-box been given the ability to choose between 3 relatively common software development processes used in our industry (Scrum, MSF for Agile [or just Agile], and CMMI) for planning and tracking work within your team(s).  Depending upon the template you choose, these processes may differ in terms of the names they use for work item types, the variety of work item types available, the amount of information fields presented, the various state transitions and names in the life-cycle of a work item, and (if configured on-premise) the SSRS Reports and SharePoint dashboards available for your team.

[table id=3 /]

The tools below have been greatly deemphasized by Microsoft in favor of more Agile-friendly, cloud-capable, performant dashboards, but important differences none-the-less in terms of the out-of-box starting point for on-premise TFS installations.

[table id=4 /]

Agile tooling, your process template choice, and customization:

Regardless of the process template you chose, you will for the most part still be able to take advantage of the agile tools to manage the life-cycle (from creation to completion or removal) of those work items.  For example, unfinished requirements (regardless of the name of the requirement work item type specified by the process template) can be prioritized in a hierarchical repository by product owners in the “Backlog” and your tasks to complete those work items can be manipulated and visualized by your team through a matrix of cards called the Task board.

However, back in the latter part of 2011, when TFS was first offered as a service in the cloud, the decision to use a particular process template took on more gravitas than it had in the past for on-premise TFS users.  Since day-one, TFS users always had the option to customize any template to better suit their organization’s needs once that initial decision of a base process template was made.  So if teams made the choice of the MSF for agile process template for whatever reason (the terminology better suited their process, or they wanted to track actual and estimated work as a tool for postmortem analysis, or they just liked the additional out-of-box reporting it provided), they were not boxing themselves into the option of only managing bugs using work item queries rather than at the backlog level which the Scrum process template provided.  This deficiency was easily remedied via a well-documented configuration change (See MSDN: Add bugs or other work item types to backlogs or boards).  Unfortunately this option of customization was in large part removed for Visual Studio Online.  Microsoft deemed it impractical to implement the preexisting mechanism of customization in the cloud if they also wanted to satisfy their goal of guaranteeing that all cloud customers could have enhancements to process and tools pushed to them without breaking those customizations.   Since 2011, through a series of major and minor releases, the agile tools have blossomed in terms of power, availability to non-licensed TFS users, and customizability (primarily as a way to re-introduce customization for Visual Studio Online users).  Although these features are typically welcome by on-premise TFS shops — especially those who were unaware of configuration customization possibilities or those who were bitten by elaborate customization gone a muck– they for the most part are yawners to that customer base.

Process template matters for option 2-Bugs appear on the backlogs and boards with tasks:  

For Visual Studio Online users, the benefits of this feature may seem obvious in that as a team, you now have the option of configuring how bugs are managed via the agile tools regardless of the process template you chose when you created the team project.  One of the not-so-obvious aspects of this feature is that if you chose option Two: “Bugs appear on the backlogs and boards with tasks”, is that your experience of this option will be only truly usable if you have chosen a process template that has mostly identical workflow state names for bugs and tasks.  For example, the state names are very similar in the Agile process workflow and CMMI process workflow.


If a team wants the ability to track bugs during an iteration alongside of tasks, the task board needs to append new columns to accommodate states of a bug not required for tasks.  In the case of the Agile template, this means that only one additional column gets appended to the board to accommodate the need for bugs to pass through the “Resolved” state before a tester/reviewer can declare the bug as “Closed.”  The task board provides visual cues by changing to green (or not) to indicate which workflow states the work item can be transitioned to from the state you are dragging it from.  For example, tasks can only be moved forward to Closed or backwards to New since they do not support a “Resolved” state.


Unfortunately this mechanism does not work nearly as well if your team is using the Scrum process template workflow where the states of a bug and task are not only very different, but have very different meanings:


The inconvenient (if not fatal) usability problems with choosing to track bugs alongside of tasks if you have chosen this process template, is that not only does accommodating all the bug workflow states at the sprint level make the task board extremely wide, but the names of the bug states and what they are meant to indicate doesn’t actually make intuitive sense.  Bugs start in the “New” to the right of the “To do” column used by tasks, but they are really at the same in-active state.  When a developer goes to work on a bug, the temptation is to drop it in the “In progress” column, but bugs only support the “Approved” state which means something on the backlog but not during a sprint.


Why this feature does not go far enough for all TFS users

While Visual Studio Online users will have to live with this working but potentially clumsy customization, my recommendation to Microsoft is to not fix this issue by renaming the states of the Scrum process template workflow states like you might think.  We need an option 4: Bugs can appear on the backlog and boards at the task level when or at the requirements level.  

This will allow allows us to represent bugs both alongside tasks when they are discovered during a sprint and alongside requirements when it is determined that the requirement can be deployed with the bug and/or in cases when bugs are discovered after deployment.

“But wait!” you say.  “Bugs classified at the task level do appear on the product backlog as child items to the requirement they were associated with.”


Yes, and kudos to the team for greatly improving the view-ability of parent-child related work items in the backlog.  (We used to have to toggle between these views.)  But work items hierarchically related do not visually prioritize well on backlog — which is one of the primary reasons we have items in a backlog.  While we can assign one bug to be fixed in a sooner sprint because it is more severe than another, that bug is visually always displayed wherever its parent is displayed in the hierarchy.

My recommendation until we have the 4th Option: 

I still recommend that on-premise TFS users create a second type of bug at the team project level that is used for tracking bugs at the task-level and give it some process-template appropriate name, e.g. “Sprint Bug” for Scrum templates or “Iteration Bug” for Agile and CMMI templates.  In the Scrum process template, I add the “Ready for Test” state rather than “Resolved” to give the state a name that reflects what should be happening when the Sprint Bug is in that state.


I described this recommendation in my previous blog article entitled  Agile Development: Keeping Daily Stand-Ups Efficient and Meaningful (Part 1) written during the TFS 2013 time-frame.

A nice TFS 2015 friction removing improvement for Visual Studio Testers: 

The reason I have rated this feature as a “mostly” yawn and not a complete yawn for on-premise TFS users is that we can taken advantage of this feature to overcome a point of process friction testers experienced creating our new “Sprint Bug” from within Visual Studio Test Manager or the web interface.  Let me explain…

Use the test tools to create Task-level bugs: 

Healthy teams have test cases typically created and executed during a sprint that must pass if we are going to call a particular requirement done.  These are typically manual tests while the feature is in the throws of creation, and sometimes converted to automated tests after the feature is released for regression purposes.  Whether or not the tester is using Test Manager to execute these manual tests or the increasingly capable web-based test case management tools accessible through the team’s dashboard, having the tool create the bug when the tester discovers the bug either while walking through the test case or while doing exploratory testing produces by far the best documented bug with the least documented effort.  For example, if the tester discovers the bug while stepping through the test can in Test Manager, he or she merely:

1. Marks the step in the test case that fails


2. Adds a comment and ideally a screen shot to best explain why the step is failing


3. Click Create bug or Update an existing bug


And voila: the “STEPS TO REPRODUCE” and fields are all filled in a beautifully readable format with Screenshots displayed within the context of the step they apply:CreatedBug

Now, since the early days of TFS, we have had no problem telling Test Manager to create our custom bug type when the tester specifies step 3 above (See, for example, the old article How can I configure MTM to use my custom bug / test case type?).


The annoying work-around for testers related to creating task-level  bugs in TFS 2013

The point of friction came that if the tester saved the generated bug it would not automatically show up on the sprint task board under the requirement the test case was associated with.  The problem was that the tools were creating the wrong link type between the bug and the requirement it was testing.  The work-around were to perform the following steps before or after saving the bug:

On the Links tab of the bug work

1. Right-click the requirement work item under section titled Related and select Edit Link…


2. In dialog Edit Link, change the Link type drop-down from “Related” to “Parent“; click OK


In TFS 2015 the annoying work-around for testers goes away

CoolThe one cool thing for even on-premise TFS customization shops is that if you both implement the task-level bug described above and configure the team with the option that you want to to manage work items at the task level, the testing tools create the appropriate parent-child relationship between the bug.  The annoying work-around is no longer necessary!

Blog postmortem: What at first blush to me was a quick little tip on how best to use this feature in TFS 2015, turned into an appalling amount of words to explain that tip.  Because it addresses so many misconceptions I find in the field, I opted to stick with the article as written rather than make assumptions about what people understand and don’t understand about TFS process templates and the agile tools.  I hope it helps some teams properly navigate these options and avoid potential pitfalls.