Two colleagues open a requirement-coverage panel in the same case management tool at the same moment and read different percentages — what accounts for that, and how do you settle which reading to quote?
answer
- the number belongs to the view
- filter, condition, cycle
- compare counts, not percentages
- permission scoping shrinks silently
basics
~20 sA coverage percentage is defined by three settings that live with the view, not with the data: the saved filter that picks the population, the covered condition, and the selected cycle. Two readings differ because at least one of those three differs.
solid answer
~40 sNothing in the underlying links or results has to have changed for two people to read different percentages. The number is produced by a view, and a view carries a saved filter that defines the requirement population, a covered condition, and a cycle scope. A personal saved filter, a default project or release, or simply a different cycle selected in a dropdown will each move the figure on identical data. Permission scoping adds a fourth possibility: a user who cannot see part of the requirement set gets a smaller population and usually a different percentage, with no warning that anything was withheld. Settle it by agreeing one named, shared filter, one condition and one cycle as the release-conversation reading, and quote all three alongside the number every time.
go deeper
Know that a coverage percentage depends on view settings, so two people can honestly see different numbers over the same data. Ask which filter and condition produced a figure before repeating it.
Be ready to enumerate the settings that move the figure — saved filter, covered condition, selected cycle — and to explain why comparing raw counts identifies the cause faster than comparing percentages.
Show a diagnosis order that starts with the population and ends with freshness, and name permission scoping as the cause that presents with no visible symptom at all.
Own the convention that makes the figure publishable: one named shared filter, one stated condition, the cycle named, and counts alongside the percentage so the denominator cannot drift unnoticed.
## The number belongs to the view, not to the data The instinct on hearing that two people see different coverage percentages is to suspect a data problem — a stale roll-up, a missing link, a failed sync. Usually it is none of those. A coverage panel in a case-management product is a **view**, and a view carries its own settings. Two people with different settings over identical data will correctly produce different numbers, and neither is wrong. The settings that move the figure: - **The saved filter**, which selects the requirement population and therefore the denominator. This is the largest single cause. Filters are commonly personal by default, and a personal filter drifts: someone narrowed it to their component during a busy week and never widened it again. - **The covered condition** — link exists, executed in the selected cycle, or passed. Three different numbers over one population. - **The selected cycle**, when the condition is cycle-scoped. A colleague still looking at the previous cycle sees the results of completed work; you, on the new cycle, see almost nothing. - **Permission scoping**, which silently shrinks the population to what the reader is allowed to see. This one is genuinely dangerous because the panel behaves normally; it simply computes over less. - **Link granularity**, where a product associates at acceptance-criterion level and one view rolls up to the parent requirement while another does not. The denominator changes size and the percentage moves with it. ## A diagnosis order that works When the two figures land in a release meeting, resolve them in this order — cheapest and commonest first: 1. **Compare the raw counts, not the percentages.** Ask each reader for the numerator and the denominator. Different denominators means it is population; identical denominators with different numerators means it is condition or cycle. That one question usually ends the investigation. 2. **Compare the filter.** Named release, component, label, date window. Check specifically whether one filter excludes requirements with no links — that filter always flatters. 3. **Compare the condition and the cycle.** Both are usually one control each and both are usually forgotten. 4. **Compare what each account can see.** Have both readers open the same named filter; if the denominators still differ, it is permission scoping, and the smaller reading is incomplete rather than wrong. 5. **Only then suspect freshness.** If population, condition, cycle and visibility all match and the numerators still differ, you are looking at a stored roll-up on one side that has not caught up. ## Settling on a reading you can publish The cure is not to find which person is right; it is to stop the figure being ambiguous. What that takes in practice: - **One named, shared filter** owned by the team, used for every published reading. Personal filters remain fine for personal work and are never quoted. - **One published condition**, chosen deliberately and stated with the number. - **The cycle named explicitly**, because a cycle-scoped figure is meaningless without it. - **The three qualifiers travel with the number** in every artefact that carries it — a status page, a slide, a message. `Coverage: passed condition, release filter R, cycle N` is a reconstructible claim; a bare percentage is not. - **Publish the counts as well as the percentage.** Nine of eleven is honest about its own precision in a way that eighty-two per cent is not, and a denominator that shifts week to week is immediately visible. ## The failure mode this prevents Unqualified coverage percentages create an argument that cannot be settled, and the settlement people reach is usually the wrong one: whoever's number is more comfortable becomes the number the organisation uses. Because the filter is the easiest of the three settings to change and the least visible, the comfortable number is almost always the one over a narrower population. The team then optimises the definition rather than the testing, and the panel — which was a perfectly sound instrument for enumerating what nobody has pointed a test at — becomes a negotiation surface. The defensive habit is small and worth building: whenever a coverage figure arrives without its filter, its condition and its cycle, treat it as an unfinished sentence and ask for the rest of it before acting on it.
- Which of those causes would you check first, and why that one?The saved filter, because it is the commonest and the cheapest to check. Ask both readers for the raw numerator and denominator rather than the percentage: differing denominators point straight at population, matching denominators rule it out in one question and send you to the condition or the cycle instead.
- How does permission scoping differ from the other causes in how it presents?It is invisible. A different filter or cycle is a visible setting the reader can name; a permission-scoped population simply computes over fewer requirements with no indication that anything was withheld. The reading is not wrong so much as incomplete, and the reader has no way to tell. That is why the shared published figure should come from an account that can see the whole population.
saying these in an interview costs you the question
- Assumes the data must be stale or corrupted
- Treats one of the two readings as simply wrong
- Compares percentages instead of raw counts
- Forgets that permission scoping shrinks the population silently