Developer questions about the spec: a question log, and where the answers go
“Quick question about the ticket” in a direct message. The analyst answers in a minute, the developer builds it, and a month later the tester files a defect against behaviour that is not in the spec. The answer existed — but it lived in a chat between two people.
A developer’s question about the spec is not a nuisance and not a sign of poor analysis. It marks a place where the text gave no answer and someone needs to keep going. Every such question exposes a hole in the spec, and every answer is a requirement the spec did not have.
The break happens not when the question is asked, but when the answer stays where it was given: in a private chat, on a call, in a code comment.
Where answers get lost
| Where it was answered | Who learns the answer | What happens next |
|---|---|---|
| Direct messages | Two people | The tester checks against the spec and files a defect on the correct behaviour |
| A call | The participants, differently | A month later two of them remember the answer differently |
| A code comment | The next developer of that file | The rule lives in code and is found only by reading code |
| The team chat | Whoever read it that day | The answer sinks under a hundred messages |
| The ticket | Everyone who opens it | The answer is checked, covered by tests and found when a defect is analysed |
One rule follows: you can answer anywhere, but the answer exists only once it is written in the ticket. A spoken question gets a spoken answer and one line in the ticket — that is enough.
The question log
It is easiest to keep questions and answers in the ticket itself, as a separate list. Not in comments mixed with discussion, but in one place that can be read in a minute.
QUESTIONS ON TASK-2071
Q-1 12.09 developer
Close access immediately, or at the end of the paid day?
answer at the moment of expiry, to within an hour
decided by product owner
reflected acceptance criterion 2
Q-2 13.09 developer
What does a user see if access is closed mid-session?
answer open — waiting for a mock-up from design by 16.09;
if it doesn’t arrive — the standard “access expired” page
Q-3 14.09 tester
Renewal in the last hour — access must not flicker?
answer it must not; scenario 3a added
reflected scenario, acceptance criterion 4The “reflected” line is the key one. It shows that the answer did not stay in the log but moved into the spec: into a criterion, a scenario, a rule. The log is an inbox, not a second place where requirements are kept.
Where the answer goes
Not every answer changes the spec. It helps to tell question types apart — the type decides who answers and where the answer goes.
| Question type | Example | Who answers, and where it goes |
|---|---|---|
| Meaning of a phrase | Who counts as an “active user”? | Analyst → a definition in the spec or the data dictionary |
| A missing exception | What if the external service does not respond? | Process owner → the scenario and an acceptance criterion |
| Conflicting requirements | Items 3 and 7 cannot both hold | Product owner → a spec edit marked “was/now” |
| No data or access | Where do we get the tariff reference table? | Analyst finds out → until then it is a blocker on the board |
| A technical choice | Keep history in the same table or a separate one? | Developer → not in the spec, unless it changes behaviour |
The last row matters both ways. The analyst should not decide technical questions — and should not let through a technical answer that changes behaviour. “We only store the latest value” sounds like an implementation detail, but it means there will be no change history.
An answer that changes a requirement is a mid-flight change. If the answer to a question changes an acceptance criterion or the estimate, everything in the piece on changes during development applies: the old value is kept, and the tester learns about it from the ticket.
A question with no answer
The most dangerous questions are the open ones. A developer cannot wait a week and at some point does “whatever makes sense”. So that this does not happen silently, an open question needs two things: a date by which we expect an answer, and a default decision if none comes. A recorded default is an assumption — visible and open to challenge. A silent “whatever makes sense” is not.
Questions as a signal
The log is useful beyond a single ticket. Looking across several tickets shows two things:
- Many questions on one ticket — it was taken before it was ready. A reason to revisit how readiness is checked at refinement, not to blame the author.
- The same question on different tickets — the product lacks a shared definition or rule. “What counts as an active user” for the third time is a signal to write it down once in the dictionary.
The sign answers are getting lost: the tester asks the developer the same question the developer asked the analyst two weeks earlier.
A ten-minute check
Take a ticket currently in progress and ask the developer: what did you clarify on it verbally? Compare the answer with the ticket text. Everything missing from the text is a requirement the tester will not see.
What next
The question log catches what the developer noticed. What nobody noticed survives until acceptance. It can be caught earlier by showing the interim result to the people who will use it.