Welcome to EMC Consulting Blogs

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:

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.

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:

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!

Linkies:

• https://www.scrumforteamsystem.com/
• https://www.scrumforteamsystem.com/Products/Search/SfTS%20v3%20Process%20template

Regards,

Crispin Parker,
Senior Practice Consultant,
EMC Consulting.