The Tellenze blog

A Finished Feature Can Leave an Unfinished Question

Agree what a delivery must prove, then give the unanswered user question a place to go. A fictional inspection app shows why both matter.

· The Tellenze team

A person in navy rests a hand on a teal canoe supported by wooden trestles beside a quiet lake.

An inspector finishes a job, taps Save and waits for the little green tick. Then she copies the readings into a paper notebook.

In this fictional example, the software team knows about the notebook. Inspectors have lost work when their connection dropped, and nobody is quite sure what the tick promises. The team has a sensible task: make saving reliable and show clearly whether an inspection is waiting on the device or has reached the office.

An engineer could finish that task. An inspector might still reach for the notebook.

Before anybody starts, the team needs to agree what each of those facts would mean.

What the green tick promises

“Fix saving” leaves too much room for interpretation. Perhaps it means preventing lost readings. Perhaps it means making the status clearer. The product owner might hear “inspectors won't need paper anymore.”

That last expectation is much larger. It involves the inspection, the connection, the handover and what people at the office do with the record.

For this delivery, the team agrees on a specific promise: the inspection remains available on the device while offline, reaches the office once the connection returns, and never appears as received before that happens. Repeated taps must not create duplicate inspections. The inspector can tell which state the record is in.

The work also has the team's ordinary quality requirements: relevant checks, review, accessibility and a release the team can support. Those requirements shouldn't have to be invented again for every saving bug.

The 2020 Scrum Guide's Definition of Done describes the quality state required for an Increment. The same guide requires the Increment to be usable and gives the Sprint Review a job beyond demonstrating finished work: inspect the outcome and decide what to adapt. There is already room here for both reliable delivery and learning about its value.

The specific saving behavior still needs its own acceptance criteria. A shared quality standard won't tell a tester whether an offline tick means “stored here” or “received there.”

In our example, the team can test an inspection through disconnection, another save attempt and reconnection, then compare the device record with the office record. It can also ask an inspector using a safe test account to explain what the status means without a developer narrating the screen.

If a coding agent helps implement the change, it can work toward the same agreed behavior and provide evidence for review. Its statement that the task is finished is a claim to inspect. The team still has to check the resulting experience.

The next week belongs in the plan

The saving change is meant to help inspectors complete and hand over their work without recording everything twice. Passing its checks gives the team grounds to deliver it. Whether the duplicate recording actually stops needs another kind of evidence.

The team can decide how it will obtain that evidence before starting the implementation.

Nia, the product owner in this example, agrees to review the next week's trial with the participating crew and the office staff receiving their inspections. She wants to follow the whole handover: which records reach the office, where people repeat work, and why. If the crew has too few inspections that week, she will report the gap and choose another observation period. The calendar alone cannot produce a finding.

This is a small investigation, with modest conclusions. A few observed jobs can expose a workflow problem; they won't establish a reliable percentage improvement across every crew.

GOV.UK's guidance on measuring service success makes a useful distinction between a transaction and an end-to-end journey. It recommends combining metrics with user research and other sources of evidence. For the inspection team, that means looking beyond the Save action to the person who receives the work.

The delivery item can retain the agreed checks and their results. The later investigation can have a linked, owned item with a question, an observation plan and a point at which the team will decide what it has learned. In Tellenze, the work-item guide describes keeping decisions and evidence with the work and linking outcome documents.

A board and a shared note can do this too. What matters is that the question survives the move to Done.

More activity can be a warning

Suppose the team sees more completed inspections after release. That sounds encouraging. It may also mean that the trial crew had more jobs, that an import was counted twice, or that people finally uploaded a backlog.

Even an accurately counted activity can have the wrong meaning.

In their 2012 paper on puzzling online experiment results, Ron Kohavi and colleagues at Microsoft describe a Bing experiment in which worse search results increased short-term query and revenue metrics. People searching more could be having a harder time finding the answer. The paper concerns online controlled experiments, not field inspections, but the interpretive problem travels well.

For our team, “more saves” is particularly weak evidence that duplicate work has disappeared. An inspector who remains uncertain might save repeatedly and keep the notebook.

Nia therefore looks for the behavior that matters and asks about the exceptions. Did the inspector finish the handover? Was anything copied again? Could the receiving person use the record? Was the notebook a workaround, a habit, or something the office still asked for?

An unanswered question belongs in the result. “We haven't observed enough handovers” is more useful than declaring success from a chart that measures a different activity.

When the fix works and the notebook stays

Now imagine that the saving checks pass and the crew can explain the new status. During the trial, Nia discovers that office staff still request a paper copy because their morning handover relies on it.

The change has answered the saving question. It has also exposed a reason the wider outcome hasn't arrived.

That finding does not excuse a broken implementation. If readings vanish or the status falsely says received, the promised delivery is incomplete. But if the agreed behavior works and its evidence stands up, keeping the saving ticket open until every handover habit changes would blur what the engineer has delivered.

The team has a new choice to make about the office workflow. It can investigate that separately, with the saving result available as evidence.

Before your next piece of work starts, try a short note with three plain parts:

The delivery promise. What exactly will be true when this change is complete, alongside our shared quality requirements?

The evidence. Which checks and observations will support that claim, and who will inspect them?

The remaining question. What effect do we hope the change will have in use, who will check it, and when will we decide what the available evidence supports?

For a simple correction, the delivery check may answer the user question directly. For a larger product change, the observation may take longer or produce an unwelcome answer. Scale the follow-through to the work.

In the fictional team's completion note, the engineer can say what was checked: offline retention, one received record after reconnection, an accurate status and the inspected release. Nia can say what remains unresolved: the crew is still recording twice because the office handover asks them to.

The notebook has finally given the team a more precise question.

Further reading