Bug

Why

When a fault or unintended behavior is found in functionality that has already been accepted and released, it is registered as a bug[1] on the Product Backlog, so it can be prioritized (and fixed).

Prepare for success

A bug is actionable when:

  • It is clearly described, including release number
  • There is a reproducible scenario
  • The intended behavior is described

How

Similar to user stories, bugs are discussed with the Development Team during Backlog Refinement or Sprint Planning, in order to make sure they are actionable.

Definition of Done[2]

  • The bug is fixed
  • Automated tests have been added and/or adjusted
  • Code has been checked in and reviewed
  • Deployed on a test environment
  • Tested
  • CI is green
  • Product Owner[3] (and/or key stakeholder) tested & accepted
  • Ready for release

Real Life Example

The app to book a shipment for parcels and packages, is also available as a web app that can be used via desktop browsers. After some user stories of the “online address book” had been delivered and gone live, it was discovered that some of its functionality did not work on Internet Explorer 10. This was registered as a bug: “Contacts autocomplete doesn’t work on IE10”. Similar to User Stories, the bug was prioritized by the Product Owner, planned for a sprint, and fixed by the Development Team. Had it been a more urgent issue, the preferred route would have been to let the Managed Services department fix the bug.

Notes

  1. Bug - When a fault or unintended behavior is found in functionality that has already been accepted and released, it is registered as a bug on the Product Backlog, so it can be prioritized (and fixed).
  2. Definition of Done - A shared understanding of expectations that the Increment must live up to in order to be releasable into production. Managed by the Development Team.
  3. Product Owner - The Product Owner plays a crucial role in the development of a great software product. He or she is responsilble for maintaining the Product Backlog.