When dealing with a client, you may find yourself trying to reconcile the bugs a client wants you to fix against the fact that agile doesn’t assign points to bugs. How can your team do the work of fixing bugs for the client when those bugs seem to have no impact on velocity? It’s real work, and the team has to do it, so how should it be tracked?
A Bug Is Not Always A Bug
The issue here is not really about tracking work on bugs. The problem is that it’s impossible to reconcile the client’s desire for bug fixes against the team’s agile agreement to complete a specified slice of functionality each sprint.
Agile doesn’t care about the contract with the client.
Product Owners and Client Requirements
One of the reasons an agile scrum team always has a designated Product Owner is to insulate the team from the issues that come up when dealing with the client. It’s irrelevant to the agile process how the contract was written, or what the client calls a bug. Agile is about determining what the team can sustainably deliver, breaking requirements down into deliverable slices of functionality, and helping the team get better at estimating those stories.
The client doesn’t get to decide what is a bug; only what is acceptable. Under no circumstances should the customer have any part in defining “done” for the team. And under no circumstances should the agile process have an opinion about what the client is paying for or what is acceptable.
The Product Owner represents the interest of the client, and works with the team to create stories that add up to the number of points the team is historically capable of delivering during a sprint according to the team’s velocity. Whether a story is treated as a bug, and not assigned points, should only be based on the state of the product at the beginning of a sprint, not on the client’s arbitrary definition.
Why Some “Bug” Stories Get Points
If a story involves taking the state of the product at the beginning of a sprint and changing it in a way that is visible to the end user, that story is feature development and gets estimated with points.
On the other hand, if a story is delivered during a sprint but not accepted as done because it does not meet the acceptance criteria, fixing the code so the story can be accepted is bug work. No points should be counted for bug fixes, regardless of whether the work is done in this sprint or the next.
Bugs in agile reduce velocity because the team was unable to deliver working functionality, not because the client calls the product’s behavior buggy.
Agile is Opinionated About Bugs, Not Contracts
Agile can help the team realize what they are capable of in a sustainable manner. It’s up to the people who write the contracts whether it makes more sense to go with a fixed price for a fixed scope, or structure the deal around some sort of warranty. The team can only deliver what it can deliver, regardless of the contract.
If you’ve found yourself wrestling with this issue, check again and make sure whether you’re talking about agile bugs or what a user might consider buggy behavior in a product. They’re different beasts, and they need to be treated differently. I’d be interested to hear your experiences with bug definitions, and how you communicated them to your team.