Welcome to EMC Consulting Blogs Sign in | Join | Help

Crispin Parker's Blog

About Scrum for Team System and .Net development

Scrum for Team System Version 3 – How to model BUGS

I was recently asked how to use the bug work item in a SfTS v3 project and as this is something I have been meaning to write about it got me thinking. Here is the result of my rambling thoughts…

Adoption of Convention.

In the SfTS v3 template we have chosen to be a facilitator and not a rule master. By this I mean that we have provided a framework to allow you to perform scrum and not a set of rules on how you should perform scrum.

This of course leads to the eternal question: How do I…?

The answer is implement an internal “Adoption of Convention”. As a company, Department, Team, or whatever type of group you are, you should discuss and decide upon a course of action that models the behaviour you require and then ensure that everyone involved follows that practice. This could be performed when scrum adoption is implemented. Once in place, you can periodically get together and review the convention. If you find it does not cover all the situations you require, then change it. Which, I hope you will agree, is all very agile.

Sooooo, how do I manage Bugs then?

Firstly, what is the behaviour you are trying to model? Here’s an example of what that question might mean to you:

  • As a scrum team I want to manage software bugs so that I can ensure they get the correct attention they require.

In SfTS v3, bugs are a description of a failure condition and not a description of work required to fix the problem. So when a failure condition is discovered, we need to create a bug work item (including all the relevant information we need to describe the bug) and adjust our backlog to describe the work needed to fix the issue.

In order to accomplish this we need to consider the bugs affect on our product backlog. When the effect is known, we then decide how we track and schedule the work to fix the bug.

“The bug describes the error condition.
The backlog describes the work.
And bugs influence backlogs.”

Modelling the Bug in your backlog.

Here is an example work flow on how you might create a bug and show how it affects your product features:

Workflow to create a bug


So lets break down that work flow a little in order to understand what actions it describes.

  1. A failure condition is discovered. This could happen at any point during the project lifecycle.
  2. A bug is created to describe the failure condition.
  3. Now we check which product features are affected by this bug.
    1. If no features are affected, then the bug has highlighted a hole in the backlog. To fix this we create a new PBI.
    2. If feature(s) are discovered, then select them for the following actions.
  4. Do the selected PBIs contain Acceptance Tests that check the failure condition? (If so who let the bugs get out!)
    1. If no test exists, create a new linked AT for the affected PBI(s).
    2. If we already have tests, select them for the following actions.
  5. Finally, link the bug to the test.

Tracking Bugs.

So far all we have done is describe the bug and how it affects our backlog features. If we want to progress and describe the cost of fixing these bugs, then we are going to have to do a little more work. By linking the bugs into our backlog, we have changed the backlog behaviour. If the linked PBI was in a state of “Done” it will be updated to a state of “Broken”. If the PBI is not “Done”, then the presence of an active Bug will prohibit the PBI from automatically being set to “Done”.

How the affected PBIs are now handled depends on their current project lifecycle position. Are they:

  • Currently active in a sprint?
  • From a previous sprint?
  • Scheduled for some future sprint?

Below is another example workflow of how you might choose to handle tracking bugs.

Tracking a bug


Once again, I’ll break down the actions of the work flow to show what it describes.

  1. The “Active” Bug is linked to an Acceptance Test.
  2. The status of the AT is automatically set to “Failed”.
  3. Is the tested PBI “Done”?
    1. If “Done”, then PBI status is automatically set to “Broken”.
      • The Product Owner is consulted to confirm if the PBI is still relevant.
        1. If true, the PBI is scheduled for further work (maybe in a subsequent sprint)
        2. If false, the PBI is set to “Deprecated” and ignored. This may occur if the historical PBI has been superseded.
    2. If not “Done”, then the action to automatically set “Done” will be blocked.
      • Is the PBI currently in an active sprint?
        1. If not, leave it on the future backlog. You might want to bring it to the attention of the Product Owner.
        2. If active; does the PBI already contain tasks that cover the bug?
          1. If true, extend the remaining duration of the task to cover bug fix the work.
          2. If false, add a new task to track the work needed to fix the bug.

It may all look horribly complicated, but when you drill down it amounts to 3 possible outcomes:

  1. The PBI is no-longer relevant (deprecated).
  2. The PBI is scheduled for future work.
  3. The PBI tasks are updated to include the actions needed to fix the bug.

So in fact it is pretty simple.

After following this Tracking workflow, you should have all the information needed to track and schedule fixing the bug. Of course, you may want to do more in your adoption of convention. For example, you might want to create tasks for future PBIs (not currently “in sprint”), so that the time cost of the bug fix is know straight away. The best solution is the one that works for your company.

Fixing the Bugs.

When you’ve confirmed the effect the Bug has on our backlog and scheduled the work, you’re ready to fix the bug. This fix might occur during the current sprint or in some future sprint. It all depends on the impact of the bug and features it effects. As Bugs are linked to PBIs via an Acceptance Test, the test should be used to confirm the bug has been rectified. The work flow for fixing bugs could be:

Fixing a bug


This looping work flow shows how the work items are passed around the team(s) until the bugs are resolved.

Ignoring Bugs.

If bugs seem like a lot of hassle, then why not just ignore them? If only that was possible! Joking aside, sometimes a bug might not be relevant and should be ignored. This is why the Bug work item type includes a status of “Ignored”. The reason a bug might not relevant could be that it affects retired functionality or maybe in the eyes of the Product Owner, the bug is in fact a design feature! What ever the reason, ignoring bugs should only be done if all the stake holders agree that the bug is in fact a red herring.

Final thoughts.

So there you have it a guide to implementing Bug handling that isn’t really a guide at all. This is only and example of what you could do. I’ve tried to add lots of “you could do it like this” or “this is one way you might do it” into the text. The version 3 template is provided to facilitate your scrum and not force you down a certain route. The nuts and bolts that make scrum work in your organisation are up to you discover. Whatever you decide to do, remember that it has to be flexible, if something doesn’t work, change it. Just make sure you let everyone know the conventions have changed!



Crispin Parker,
Senior Practice Consultant,
EMC Consulting.

Published Thursday, June 24, 2010 3:27 PM by crispin.parker

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Crispin Parker's Blog said:

With the recent launch of the new Microsoft Scrum template , I am often asked about a feature comparison

June 28, 2010 1:12 PM

Aidan said:

A quick question:

We've generated a bug from an acceptence test that failed, which should be covered by an existing task. The task is marked as done and it's not possible to extend the duration or set it back to In Progress.

Do we need to create a new task and should the original task not have been marked as done until the acceptence test had passed?

June 28, 2010 1:24 PM

crispin.parker said:

Hi Aidan,

Personally, I would create a new task. The "Done" state of a task should be immutable (well very nearly). You could argue that the addtional work was not identified until after the test was run, so this would lead to the creation of a new task. But, that's only my opinion.

Have a think about your internal conventions around this suituation and get everyone to agree on the correct behaviour.


June 28, 2010 2:03 PM

Anushree said:


I created a bug and I want to assign to one of the developers but bug creation screen doesn't provide any such option where I can assign it to developer.

Please let me know how to do that?

July 8, 2010 11:38 AM

crispin.parker said:

Bugs are not used to track work, that is done on the product backlog. I think I might have mentioned this somewhere.

So, create tasks or backlog items as required and then you team can take ownership.

A better place to ask questions on the Scrum for Team Sysstem version 3 template is: http://www.scrumforteamsystem.com/QA


July 8, 2010 12:43 PM

Anushree said:

Thanks for your quick reply on my post.

I have some more doubts regarding bug workitem in V3:

What is the significance of field 'Assigned To' in bug report?Whenever we see history of bug creation or updation, it shows 'Assigned To' field,which by default shows the user who created the bug(which is actually incorrect).

Also when we export/download EMC SCRUM process template and try to edit bug.wit ,it clearly shows 'Assigned To' as one of the fields in field list,if user can not update it directly why is it there?

As per Scrum template v3 we can only link a bug with an acceptance test and acceptance test with a product backlog item.As per your suggestion team can take ownership of PBI related to the bug,in that case bug can not be assigned to one team member but will be assigned to a team,is that correct?

Please confirm.I'm also posting this query on the URL suggested above

Thanks in advance.

July 9, 2010 9:25 AM

crispin.parker said:

Hi Anushree

The "AssignTo" field is only present in order to support the integration into the Microsoft Test Manager application. In order to work within the MTM the bug work item must support the wacky assignment functionality you have mentioned. I would have been much happier to remove all assignment fields but it was not an option.

"Assigning" work to a developer isn't very Scrum. In Scrum, the team members should take "Ownership" of the sprint tasks. If you do want to assign work, then it could be done at the task level. Sprint backlog tasks have an "Owner" field that could describe this.

You should consider the desired bug handling behaviour when you define your internal conventions. My suggestions on how to handle bugs are just that, suggestions. If your internal adoption needs addtional steps, bug assignments or regualr team beatings, then add them into your conventions.


July 9, 2010 9:51 AM

Leepe said:

Mr Parker,

I am inspecting the SFTS template as our new standard template.

I did a kickoff with a Product Backlog and some Sprint backlog items.

Now the problems arise:

1. I am using Test Manager (MTM) for adding Requirements (Acceptance tests)

2. SMW does not refresh automatically so restart SMW

3. Link the Item on the Product Backlog Item via SMW

4. Finish Sprint Backlog Item => PBI set to DONE (GOOD)

5. Create a Bug on the ACT via MTM => PBI set to BROKEN (GOOD)

6. Bug is not linked to ACT via Failed by (BAD) but is found in the links tab

7. ACT state is not changed to failed (BAD)

Further I really like the concept but the integration is not as smooth as I would have wanted it to be. The SMW is nice but has some downsides more specific to refresh options and some bugs in adding items. Could you deliver me some insight and\or acknoledge if the problems that I state are valid! A guidance and best practices of the SFTS template in scrum would be nice. And especially with integration of MTM. I am glad to share my experience, as I would like a process as smooth as possible.



July 13, 2010 9:42 AM

Leepe said:

Mr Parker

Adding an Active Bug to an Acceptance Test does not change the state of the later.

AT stays Ready for test if an active bug is added.

I think does not act as it should? Following the guidelines this should be changed.



July 13, 2010 12:36 PM

crispin.parker said:

Hi Leepe,

Thanks for the feedback. Also, a question in the Scrum for Team System Q & A has highlighted an error in the "Bug -> Acceptance Test" event service rules. You can see the fix in the following link:



July 14, 2010 12:04 PM

Dave M said:

What link type do you recommend for linking tasks to bugs?

October 14, 2010 3:56 PM

crispin.parker said:

@ Dave M - I would use the standard "Hierarchy" link type.

October 14, 2010 4:02 PM

Mike O said:


I just watched Simon Bennett’s presentation at PDC 09 in Nov.   My question  is regarding regression testing.   Simon mentioned that AT’s could be accumulated and run as part of a cumulative regression test.     Trouble is he did not mention a dedicated time slot for QA engineers to execute these ATs.    My assumption is that Simon recommends the team review the accumulated set of ATs and select (based on risk to the project) which ones to be executed against a build that is slated for release.    I maintain that any release must have a dedicated regression cycle to vet the cumulative work done by the various sprints to provide confidence that recent code implementations did not compromise earlier functionality.


November 9, 2010 6:38 PM

Dave M said:

We've been using sfts v3 for a while now, and I must say that I've been very disappointed by the complexity of how bugs are modeled. I cannot just take ownership of a bug.  I need to create a task, an acceptance test, and a PBI, if those haven't all been created for me. That's a lot of work, and to me, it seems, very un-agile. A lot of times, I just want a bug to be a bug. I think it's great that a bug can be linked to all of those other artifacts, but don't force me to do it in order to get my work done.

A bug is work - something that needs to be addressed - whether it is linked to a task or not. Why not let it stand on its own as a "work item", which it is? Let the work item state handle whether the team is going to actually address it or not - not the fact of whether it has an associated task.  I am tired of looking at bug lists, and then having to follow the links to tasks to see if anyone is working on them. I am tired of having to close out both a bug and a task when I am done fixing the bug. Oh yeah, and I need to transition the state of the acceptance test too.

To my knowledge, this is the only TFS process template that doesn't allow ownership to associated directly with a bug. The same goes for acceptance tests.

Sorry for ranting, but this is very annoying. Perhaps you could give some guidance for people who would like to modify sfts v3 to behave more like other process templates, which allow for direct ownership of bugs and acceptance tests? We tried doing this at one point, but found that the ownership field was getting overriden. Are there any other pitfalls to look out for?

November 9, 2010 10:52 PM

crispin.parker said:


I wrote this blog post because I feel this is the correct way to model bugs. IMO using clear elements with single responsibility makes the project easier for everyone. But then I'm a developer that likes clear backlogs and easy effort tracking, having effort scattered all over the project just doesn't feel right.

If my suggestions don't work well for you then you can either customise the template (see Microsoft’s TFS Power Tools for an excellent UI template editor) or try an alternative template like Microsoft Visual Studio Scrum v1.

As I have stated throughout the blog post you are responding to, it's all about your own adoption of convention. If you're having trouble with the current convention, then get all the stakeholders together and hammer out a better alternative.

You’re an empowered agile professional. So take control and get your tools working how you think they should. As I like to say:

"It is better to light a candle than to curse the darkness."

Pep talks over, go do it!



Crispin Parker,
Senior Practice Consultant,
EMC Consulting.

November 10, 2010 9:40 AM

Dave M said:


Fair enough, and thanks for your suggestions. The team I am on has been reluctant to make modifications to the process template, due to bad past experiences modifying other tools similar to TFS. But perhaps I can convince them that it is worth the effort. I'm a little concerned about how will it affect things like ScrumMaster's workbench if we start changing things.

We could try switching to another process template, but I'm concerned about losing all the work we've done using the sfts process template. Is it hard to transition from one process template to another?


- Dave

"I'd light a candle, but I've got a couple of impediments: 1. All my candles are locked in a darn cabinet. 2. All my darn matches are wet."

November 10, 2010 2:14 PM

Gustav said:

I agree with those stating that it would be nice to have an "Assigned to" field visible for Bug work items. And as Dave says, this can pretty easily be done by adding it in the bug.xml file.

But has anyone done this? I am a bit worried about how it will affect the data already in the TFS and how for example the web portal with handle a change in the xml file.

June 27, 2011 12:45 PM

Andres said:

Hello Crispin,

Can I change the names of the states in the bug state workflow without breaking Test Manager Integration or Reports?


June 30, 2011 9:15 PM

Renju said:


I assigned a particular person for writing testcase in testmanager.

Now how can i see the person name if i open the Acceptance test through Work bench.

November 21, 2012 5:49 AM

Leave a Comment


This Blog



Powered by Community Server (Personal Edition), by Telligent Systems