Thoughts on Bugs and Chores

I’m not going to detail every feature of the Pivotal Tracker tool because, like I’ve said before, the process is more important than the tool. #agileforteams is about the process. However, Tracker does have two other major items in a given Backlog that are worth covering as they get used a lot: Bugs and Chores.

Bugs

Every software application will have bugs, so you should track them along side your feature work. In Tracker we interleave Bugs with stories/Features in the Backlog. Bugs however don’t get assigned points as they are a sunk cost. Their estimate of value (points) was part of the story that created the bug in the first place. This means that if we did assign Bugs points, we’d be double-counting that effort, which throws the Velocity off.

Just as any member of the team can create a story, any member can also create a bug. Defining a good bug is probably a discipline unto itself so I won’t go crazy on that. Apply pragmatism: What’s the minimum a Bug needs to be understood in terms of this is resolved when and what the impact of said bug if left unresolved?

Signup form doesn’t hide optional fields on IE6

Impact: Only IE6 users won’t have a shorter form. All fields will be present and visible. It just makes for a slightly poor UX.

this is resolved when: * the optional fields section loads as hidden on a new/empty signup form load

The example above is usually enough for a PO to prioritise the bug and the developer to get it to Finished. A PO or the person who raised the Bug should Accept/Reject it.

Lastly, try not to assign a dedicated team member to Bug at the expense of Feature work. I’ve seen this create specialisations and damage morale. Ideally, these patterns and practises work best with cross-functional teams and self-organising players. If you must dedicate someone, ensure that it’s for a limited season and if it happens regularly, rotate the responsibility around the team.

Chores

A Chore is something that needs to be done in the course of the product/project that makes sense to track with all of the other work because it consumes capacity of one or more team members. If you don’t include these things somewhere, then if this kind of work begins to make a measurable difference to Velocity, you won’t be able to track down the root cause.
So the first tip is: Better to create a Chore than not.

Then after you’ve created the Chore, think about what that work adds to the team/product and whether it can be expressed as “value delivering” and therefore in the form of a story. Often infrastructure work (setting up VMs, build pipelines, automation, etc) seems like an obvious choice for Chores only these tasks can consume considerable team capacity. Instead, rephrase the work into stories - after all, most of them will deliver value to the product. It can be difficult equating these types of work to the regular development work when you open up the Done column, but nevertheless try. A corpus will form over time making this base of reference for estimating easier. Where something can’t be phrased as a story or it’s taking too long to do so, just leave it as a Chore. If over time you find too many chores and suspect a meaningful loss to Velocity then bring it up and the Retro: inspect and adapt.

Just like the Acceptance of Bugs isn’t as strict as Features, stories that come out of Chores sometimes make sense to be Accepted by a non-PO. If the PO has the technical understanding and can exercise the AC then great: prefer to have the PO Accept it. But if not, then another technical team member could Accept it also. Just try to avoid the author of the work doing the Acceptance. It’s just like an Author of a major Pull Request merging it - it’s not a good practise.