ALM Rangers ALM Dogfooding … dealing with bugs on tfs.visualstudio.com – Part 8

Bugs?

We are not talking about these interesting colleagues …

… but about the Work Item Type “Bug”, used to report missing or incorrect features, crashes or other unwelcome guests in software development lifecycles.

During the course of our dog-fooding adventures we noticed a few challenges appearing in a few of the teams in terms of identifying bugs and dealing with them in a controlled manner. This post summarises the challenges and our Ruck Guidelines that we are considering based on feedback from the project teams.

Challenges

Here are the four challenges we encountered to date, which initiated the discussions around bug tracking and management, and this post.

1 – What, we have bugs?

Often the teams only became aware of bugs when the Ruck /Support team monitoring an aggregated backlog and view on projects mentioned the elusive critters. Upon investigation it became apparent that teams were (razor-sharp) focused on their task boards. Therefore bugs streaming in using incompatible sprint and area values simply disappeared in a black hole … until the Ruck / Support team queries or the team started their end-of-sprint backlog pruning.

 

2 - Is it a PBI or Task?

Once a bug appears on the task board it is often not easy to distinguish between a product backlog item (PBI) and a Bug. As shown in the example on the left both the “Image quality needs to be improved” and the “Deal with Snapped View and Filled View as well” sound like potential bugs. The first is indeed a bug, whereas the second is a product backlog item.

 

3 – Who owns the bug and what are the tasks?

Who owns the bug … the (a) creator, (b) project lead, (c) product owner or (d) team member? … it depends.

4 – How do we track the resolution effort for bugs?

Once bugs are found, teams started resolving and closing them. The project teams submitted their sprint reports with a … which turned into a when they were asked for effort / investment in terms of time needed to resolve the bug(s). The Bug WIT effort field was often found to be incomplete or inaccurate …

 

---

Ruck Guidelines

In this section we will explain the guidelines we are currently dog-fooding. It is important that the use of guidelines, instead of process, is intentional as we are merely recommending an approach to the teams at this point.

Ruck / Support Team – “high altitude” view

Reading ALM Rangers ALM Dogfooding and the “Angst” Factor – Part 3 you realise that we are using few team projects, containing a number of teams, which in turn can contain one or more feature teams … similar to a Russian doll. The Ruck / Support team has created a number of queries featured on the aggregated team project home page, which gives an early warning of smoke.

The “All Bugs” query crawls through all teams and allows us to keep an eye on the overall bug debt. Clicking on the tile, we get a more detailed list which also highlights the feature team in the Area Path column:

Project Team – “in the trenches” view / process

To get a complete view of the project team and answers to their challenges let us join a team that is currently in-flight and is iterating through the Talk/Listen and Act process.

	See ALM Ranger solution types and a practical walkthrough of the Quick Response concept (Part 2) for more details.
At some point step (1) TALK/LISTEN above will translate to the (1) CAPTURE “bug” event in the refactored diagram on the right. The team then …. (2) analyzes the bug and ensures that the context, impact and implications are understood (3) creates a fix, which translates into (4) one or more bug fixes and associated task Let us have a more detailed view of each of the first four steps.

STEP 1 – FIND BUG … and report properly

Guidelines

Challenge Resolution - We address challenge #1 and #2 by capturing “good” data

The concept of “garbage in – garbage out” (GIGO) is an old, but still very applicable! It is important that we educate and guide anyone who captures a bug to take special care when capturing the bug. For example: Title is the first and most often viewed Bug field. Ensure it is self-explaining and if you battle to describe the bug in one title, it is probably worth breaking down into a number of associated bugs. Prefix with Bug: to reinforce the type. Effort and Severity fields are important for the triage team. Description and Attachments should be used to add context and evidence to the bug. Area Path must be set to the appropriate feature team. Assigned To must be assigned to the project lead (PL) or left blank if the originator is unsure who the PL is. Incomplete or bad data in a Bug WIT results in unnecessary delays or bugs from vanishing off the radar. Other teams often don’t create bugs for one found by the team and only for those found outside the team. The thought being the bugs are fixed right away as part of the sprint since they were found in the sprint. The ALM Rangers encourage the capture of bugs and associated tasks for traceability and to ensure that nothing gets lost in the distributed, disconnected world we operate in.

The team now sees a clear difference between product backlog items (prefixed with MMF above) and bugs. Even on the task board, the BUG (lights) up

STEP 2 – UNDERSTAND CONTEXT … and create associated tasks

Guidelines

Challenge Resolution – We address challenge #3 by breaking down the bug into actionable tasks

The project lead should keep an eye on all bugs assigned to the project team, triaging new bugs and working with the team to define a set of actionable tasks. Triage Project lead takes ownership of the new bugs and performs a triage which can be discussed during the second half (general issues) of the at the next stand-up meeting. Revise captured information to ensure clarity and accuracy. Prioritise the bugs that fall below the quality bar. For example if your quality bar states that no critical bugs are acceptable, you should focus on critical tasks before auctioning high, medium or low bugs. The project lead works with the product owner in terms of prioritization and the decision to take on the bugs as extra work during an ‘in-flight” sprint. Assign the bug to a team member that assumes ownership of the bug. Set State to Approved. Set Iteration (sprint) to the root path of the project to be picked up in the next backlog planning session or assign to a specific iteration (sprint) during which bug must be resolved. Link the bug to the associated parent Epic or PBI. Actionable Tasks The owner of the bug breaks down the bug into actionable tasks, which are subject to the GIGO concept as well. Each task has the bug as parent. Either assign the tasks to specific team members or allow team members to grab one task at a time.

The team has a list of bugs and tasks that must be completed to resolve the bug. Ownership has been clarified and remaining work data allows us to quantify the effort and cost.

STEP 3 – FIX … and track the BUG

Guidelines	Challenge Resolution – We address challenge #4 by keeping remaining work data up to date
Keep track of effort! The owner of each task associated with a bug must keep the State of the bug and the Remaining Work fields of the associated task up to date. Engage originator of bug for validation (ASAP) When all tasks are Done and the bug is fixed the originator of the bug is notified an asked to validate the resolution.	The burn down charts now visually include and report the effort associated with bugs. While we create ad-hoc spikes in the burn-down charts, the benefits of visual tracking far outweigh the scope-creep discussions caused by the spikes.

STEP 4 – RELEASE … and report on resolutions

Guidelines	Challenge Resolution – We close the loop and maintain transparency through open communication
Document the team’s achievements! Include all achievements of the team, which includes bug fixes, in the “show what we have” announcements. Clearly identify fixes List all resolved bugs and associated fixes, as well as queued bugs.	We all love the sun (transparency) over a black hole … so be as transparent as possible

We would love to hear your challenges and solutions to the management of “bugs”.

 

---

Related posts

Dog fooding Series

Comments

• Anonymous
  December 05, 2012
  The comment has been removed

• Anonymous
  December 06, 2012
  What would a day be without a smiling :) emoticon? To ensure we can improve our posts, can you please elaborate where and why the emoticons are making it more difficult to read?

• Anonymous
  December 28, 2012
  For example, in the "Keep track of effort!" section. It seems that the crescent moon is unintentional? The others, however, are fine. (Not sure why the one stood out so much when originally reading this...)

• Anonymous
  January 18, 2013
  Brian, sorry for the crescent moon. Yes, it was unintentional and out of place.