Avoid the Bug as Task anti-pattern in Azure DevOps

For the last few months, I have been working with an enterprise customer that has been steadily adopting Work Item Tracking in TFS. I have learned that you should avoid the Bug as a Task anti-pattern.


  • 2023-10-10 – Updated to reflect Azure DevOps, and spelling fixes.

The customer that I have been working with is fairly large and there are quite a few DevOps Consultants helping them out. My task was to onboard one department of about 120 people and ~10 teams. Incidentally, these teams are, for the most part, Java teams. As with any enterprise, there are things that departments can decide for themselves and things that are handed down from on high and they are often fond of ‘laterals’. A ‘lateral’ is a group of people who get together to make arbitrary and unilateral decisions about how a process should be implemented. Problems arise when these groups start prescribing the “how” and not just the “what”. They start making technology decisions oh “how” things should be implemented, not necessarily understanding the technical ramifications.

To be fair in enterprise most ‘laterals’ take ownership of the process and leave the implementation of that process to the consultants on the ground. They push down responsibility for the ‘how’, while maintaining the ‘what’, to those best placed to make those decisions. However in this case the testing lateral has maintained ownership of the ‘how’ as well. Although they inherited the Bug as Task anti-pattern from the choice of the Agile for MSF template, having ownership of the ‘how’ means that those implementing do not have the lateral to make changes. This often causes a certain amount of friction as the teams adopt the tool. Agile teams, or teams moving to agile, are often restricted by the bug as a task anti-pattern.

Why is Bug as a Task an anti-pattern?

Now you might be forgiven for coming down on the side of governance as ‘we need some guidance to come from somewhere’. With many having organisational mandates to move towards agility, they are however unknowingly making decisions that are making the tooling a friction point for that move.


These decisions are often the result of the traditional silo-based delivery experience that has them not avoiding the Bug as a Task anti-pattern in TFS. If you are doing all of the development before you test then this is a necessary configuration. However, as we know that this is inherently dysfunctional making this compromise is sweeping issues under the rug rather than dealing with them. So why is having a Bug in the same domain as a Task a bad thing?

  • Not transparent – if you do not have bugs on the backlog, then you no longer have a single unified, visible, and transparent list of things that you are working on. If you have two places to go, backlog and buglog, then how do you know priority? Suddenly you have two masters, the list of things hat the PO wants and the list of stuff we did not finish. In extreme circumstances, this buglog is not shown to the Product Owner. This is then getting pretty close to the line of fraud. Customers should always be fully aware of bugs.
  • Promotes low quality – it’s a little weird, but in my experience, if you have a way to be pedantic, then people will use it. Provide a way for the teams not to communicate and you may very well find them trying to communicate through work items. Avoid this at all costs. They are not there as a crutch for poor team communication. They are there to provide long-term traceability and to support the team’s efforts to maintain priority.
  • No predictability of planning – no really. If you have this many hidden bugs, your PO is not going to be able to understand what it takes to complete anything. If your bug rate is high then your technical debt is high and you are not really ever done. If you are not really done then you should get no points for that item.

So if there are all of these downsides why would you want to have bugs as a task. Well, maybe I do want to hid my bugs from a customer, but apart from the nefarious reasons, I can think of only one good reason: low quality.

Where does the Bug as a Task anti-pattern come from?

If your software quality is so low that you repeatedly and consistently have many hundreds of small bugs then I can imagine the pain of always having to create one Bug and then one Task to fulfil that Bug. I see time and again teams creating PBI’s called ‘Bug Bucket’ to hold the many smaller bugs so that the PO can prioritise them and so that they appear on the boards. If you are a product owner then do not put up with this! Ever! You should be able to prioritize one bug over another, or choose not to fix a bug at all. And if the bugs are too small for you to care about why are they not just fixed rather than spending time tracking and updating them?

Now that we understand the problem, we can dive a little deeper. We have discussed the symptoms of the bugs as tasks anti-pattern above but what about some of the causes and by inversion, solutions?

  • Poor communication – If your testers and your coders don’t talk then a lot of small things will drop through the cracks. Poor communication is a people problem and can only be solved there. Don’t try to paper over the issue. Solve it…
  • Testing outside of the sprint – Even if your team has good communication if the testing is not happening at the same time as the coding then things will get left behind. Your coders wild not be in the same headspace as when they originally wrote it, and then the testers are re-testing out of context. Poo..
  • No test first – We need to have an idea of what we will be testing for before the developer begins to code. If you don’t know enough to create at least one functional test then you should not be bringing it into the sprint. Think about it. The functional tests are the things that you use to measure whether the coder built what the customer asked for. If it is the measure you use to determine the correct outcome, then now can the coder ever be able to meet it without having it at the start? Make everyone’s lives easier and eliminate rework by creating functional tests upfront. I often have to work with teams to help them understand what this looks like, however, they can very quickly get going with a little coaching.

How do we deal with the Bug as a Task anti-pattern?

While the solutions above will work, they need to be owned and implemented by the Product Owner and the Development Team working together. Make things open and transparent and push the problem down to the people causing it. Yes, the development teams should have to create a Bug at the PBI level and then break it down into Tasks. Yes, even if they have to create a Bug and a Single task for a 10-minute piece of work. This is their penalty for not communicating effectively. If the PO is not providing enough detail in the PBI then their penalty is having to prioritize tonnes of little meaningless bugs.


By forcing the teams to treat all bugs as backlog items you force them to take a long, hard look at when they create a bug and how they deal with unfinished in-sprint work.


Avoid the Bug as a Task anti-pattern in TFS at all costs. It promotes dysfunctional teams and will create friction for your teams that are doing agile. If you are still trying to decide in the process template or you have realised your mistake and want to fix your process template I have some posts to help. If you are on the right path, then awesome; however, resist all pressure to create Bug as a Task and focus instead on creating awesome agile requirements that include tests written upfront.

Upcoming Training Opportunities

These are the next five classes we have, and you can check out our full public schedule of classes.

Live Virtual Product Backlog Management Skills with Joanna on 14th December 2023
Virtual Traditional
14-15 Dec, 2023
09:00-13:00 CET
2 half-days
Immersive Professional Agile Leadership Essentials with Joanna on 12th January 2024
Virtual Immersive
12 Jan-1 Jan, 2024
13:00-17:00 GMT
8 weekly half-days
Immersive Professional Scrum Product Owner with Martin on 17th January 2024
Virtual Immersive
17 Jan-6 Jan, 2024
13:00-17:00 GMT
8 weekly half-days
Immersive Professional Scrum Master (PSM) with Dan on 17th January 2024
Virtual Immersive
17 Jan-28 Jan, 2024
13:00-17:00 GMT
7 weekly half-days

We can deliver any of our courses as private in-house training over Microsoft Teams & Mural. We also recommend training based on your accountabilities or role, you can go directly to recommended courses for Scrum MastersProduct OwnersDevelopers and Agile Leaders.

Create a conversation around this article

Share on Facebook
Share on Twitter
Share on Linkdin

Related Courses

Scrum for Teams


Enables all members of the Scrum Team to learn Scrum while doing it, experiencing what it is like to deliver products using the Scrum framework

Scrum for Software Development


Experience APS-SD: Hands-on Scrum training for delivering quality software. Gain practical skills in Agile, DevOps, and Scrum principles. Free PSD I certification exam included. Enhance your software development expertise.

Read more

Martin Hinshelwood NKDAgility.com
https://youtube.com/shorts/Ce5pFwG5IAY Scrum Masters: Unlocking the Power of Liberating Structures 🚀  In the dynamic world of Agile and Scrum, Scrum Masters are continuously seeking innovative ways to enhance collaboration and effectiveness within their teams.  Introduction: Embracing Liberating Structures in Scrum  One transformative approach that’s gaining traction is the use of liberating …
Martin Hinshelwood NKDAgility.com
Business Leaders face a key challenge when scaling their organisations effectively while maintaining the distinctiveness that made us successful in the first place. Many frameworks and methodologies, such as Scaled Agile Framework (SAFe) or the Spotify Model, promise a structured approach to scaling, but do they genuinely fit our unique …
Martin Hinshelwood NKDAgility.com
As we inch further into the dynamic landscape of the 21st century, our long-established Alpha organisations stand on shaky ground. The organisations whose DNA is infused with strict command and control, woven into the fabric of every process, are feeling the tremors of a rapidly evolving, technologically charged market. Not …
Martin Hinshelwood NKDAgility.com
Under the ruthless canopy of the red market, I find myself staring at the bloated behemoth of an Alpha organisation, huffing and puffing in a vain attempt to keep up with the frenzied pace of the modern world. The Alpha model, once a paragon of order and efficiency in the …


We believe that every company deserves high quality software delivered on a regular cadence that meets its customers needs. Our goal is to help you reduce your cycle time, improve your time to market, and minimise any organisational friction in achieving your goals.

naked Agility Limited is a professional company that offers training, coaching, mentoring, and facilitation to help people and teams evolve, integrate, and continuously improve.

We recognise the positive impact that a happy AND motivated workforce, that has purpose, has on client experience. We help change mindsets towards a people-first culture where everyone encourages others to learn and grow. The resulting divergent thinking leads to many different ideas and opportunities for the success of the organisation.