Playbook 8 · Writing the work

How to raise a bug

A bug is a defect in something already shipped. If it's a missed requirement, it's a story, call it what it is.

Why it matters

Bugs auto-link to the current quarter's Bug Budget epic. The burn rate becomes a quality signal you can trend. That only works if the team distinguishes real bugs from missed scope, and writes them so they can be reproduced.

Step by step

  1. Title: what's broken, not how it feels. "Logout button does nothing on Safari 17", not "logout broken".
  2. Steps to reproduce. Numbered. Should work cold for someone who's never seen the bug.
  3. Expected vs actual. One line each.
  4. Environment. Browser/OS/version, role/account, time-of-day if relevant.
  5. Severity. Critical (broken for everyone) → High (broken for many) → Medium → Low.
  6. Attach evidence. Screenshot, video, log snippet, request ID.
  7. Don't dual-purpose. If you noticed three things, raise three bugs.

What good looks like

  • Reproducible from cold
  • Severity set with rationale
  • Expected vs actual stated
  • Evidence attached
  • Auto-linked to the current Bug Budget epic
  • Single-issue per ticket

How Tenhaw runs this

Every bug auto-links to the current quarter's Bug Budget epic, so burn rate becomes a quality signal you can trend. The bug template enforces reproduction steps, expected vs actual, severity and evidence. No half-written tickets.

  • Tenhaw RAID Logs
  • Tenhaw Bug Budget epic
  • Tenhaw severity scoring
  • Tenhaw quality trend analytics

Try this on the Tenhaw platform →

If a bug exposes a deeper problem, raise an RCA ticket, see the RCA playbook.

Related playbooks

9How to write a risk or issue 7How to write a chapter 6How to write a story 1How to set an outcome

Run this in your team

The Tenhaw product enforces every rule in this playbook so it doesn't sit on a wiki gathering dust. Try Tenhaw or book a working session with the founder.