Closing an issue because it did not happen on your machine settles nothing. Four places the difference usually hides, and the one question worth asking first.
Read it →Compound issues stall because there is no single thing to finish. How to spot one, and how to split it without losing the thread that connected the parts.
Read it →Acceptance criteria without the ceremony. Three questions that settle what finished looks like while it is still cheap to disagree.
Read it →Most bug reports are relayed, not witnessed. What gets lost between the person who saw the problem and the person who wrote it down.
Read it →We need a dashboard is not a requirement, it is a conclusion. How to get back to the problem someone had before they solved it for you.
Read it →Backlog issues are read by strangers, and the most common stranger is the author with four months of forgetting in between.
Read it →A meaningful share of bug reports are disagreements about intended behaviour. They are cheap to spot on day one and expensive to discover in week three.
Read it →Most reproduction steps begin halfway through, from a state only their author had. Four rules for steps somebody else can actually follow.
Read it →The most common bug report in the world is also the least useful. Here are the eight distinct failures it hides, and the one question that separates them.
Read it →The cost is not the developer's confusion. It is the wall-clock delay of a question crossing a timezone, multiplied by every unclear ticket you take.
Read it →Most bug reports are missing the same five things. Here is what to ask, why each one matters, and why teams so often do not ask at all.
Read it →Templates ask everyone the same questions regardless of what they are reporting. Here is why that fails, and what a template can realistically do instead.
Read it →