5 exercises on describing impact precisely — blockers, regressions, frequency, workarounds, and severity vs priority.
Key patterns
Blocker: work cannot proceed and there is no workaround.
Regression: previously working behaviour now broken — cite last good vs first bad version.
Quantify frequency: 1 in N, ~12%, 5/40 runs.
A workaround usually lowers priority, not severity.
Severity = impact; priority = scheduling urgency. They are independent.
0 / 5 completed
1 / 5
A login page returns a 500 for all users in production. Which sentence describes the impact most precisely?
Impact statements quantify who is affected and how badly. Option B names the scope (all users), the environment (production), the rate (100% of attempts), and the consequence (effectively down) — exactly what a triager needs to set severity.
Blocker = work cannot proceed and there is no workaround.
Distinguish severity (technical impact) from priority (business urgency for fixing).
State the affected population: all users, ~5% of EU traffic, admins only.
Option A and C understate a total outage ("a bit broken", "occasionally"). Option D is all emotion and exclamation marks with no facts — never let urgency replace measurement.
2 / 5
A feature that worked in the last release is now broken. Which term and phrasing should you use?
A regression is a bug where previously working behaviour stops working after a change. Naming it as such is high-value: it tells the team a recent change is the cause and often points to a git bisect between two versions.
Always cite the last good and first bad versions (v4.2 → v4.3).
Collocations: introduce a regression, regression test, regression range.
Contrast with a net-new bug in a feature that never worked.
Options A and C avoid the precise term and add blame ("someone broke it"). Option D calls a fresh regression "quite old", which misleads triage.
3 / 5
There is a clunky way to avoid the bug. How do you communicate the workaround and its effect on priority?
A documented workaround usually lowers priority but not severity. Option C states the concrete alternative (export as PDF), acknowledges the cost (inconvenient), confirms it unblocks the user, and adjusts priority accordingly — the exact reasoning a backlog owner needs.
The presence of a workaround typically moves Blocker → High.
State whether it fully or partially unblocks the user.
A workaround does not close the bug (Option D is wrong) — the real fix is still owed.
Option A is too vague to be a workaround. Option B ignores the workaround and inflates urgency.
4 / 5
How should you describe how often an intermittent crash happens?
Frequency belongs in numbers, not adjectives. Option B gives a rate (~1 in 8, ~12%), the triggering action (reopening from background), and a reproduction count on a named build (5/40 on v4.3). That is enough to gauge severity and to verify a fix.
Use proportions: 1 in N, ~12% of sessions, 5/40 runs.
Tie the rate to a condition (cold start, low memory, specific input).
"A lot", "sometimes", and "every now and then" cannot be acted on or verified.
Quantified frequency is also what lets you say later "fixed — 0/200 in the new build".
5 / 5
Which statement correctly separates severity from priority?
Severity and priority are independent axes.Severity describes impact if the bug occurs (data loss, crash, cosmetic). Priority describes scheduling urgency given everything else on the backlog.
Option C captures the key insight: a crash (high severity) that hits 0.01% of users monthly and has a workaround may be low priority, while a typo on the pricing page (low severity) can be high priority because it affects revenue and trust.
Common ladders: severity = Critical / Major / Minor / Trivial; priority = P0 / P1 / P2 / P3.
Justify your rating with impact + frequency + workaround.
Options A, B, and D confuse the two or reduce them to mood, which leads to mis-triage.