If a feature keeps coming back for corrections, an earlier check of the assumptions behind it may save another pass through implementation. To reduce development time in that situation, bring useful feedback into the work while there is still little code depending on a decision.

A hypothetical team is adding a CSV export to an existing report. Everyone agrees that exported data must follow the report's permissions, but the acceptance examples only describe the file format. The developer finishes the export, then acceptance testing reveals that a user with limited access can download records they cannot see in the report. The team must change the implementation and check the behavior again before release.

Rework keeps the clock running

The corrections extend the export's development cycle time because the feature still needs work before release. Here, that time runs from the start of active work on the feature to its deployment in production, after its acceptance checks pass.

The time spent investigating and validating the feature belongs in that interval. If the team starts checking assumptions earlier but starts the clock at the first commit, some of the work disappears from the comparison. Preparation still takes time, and any reduction needs to hold when that time is counted.

DORA's testing guidance describes how feedback received after a team calls development complete can require substantial correction, including changes to the design. It recommends testing throughout development so that the team can discover problems while the work is still taking shape.

The permission requirement was already agreed, but the acceptance examples didn't show which records each user should receive. That gap explains the return to implementation in this example. A team whose changes spend most of their time waiting for review or release has a different problem to investigate, covered in the guide to finding delivery bottlenecks.

Define the behavior first

The developer and the people responsible for product and testing need to agree on the records each user should get. Comparing the report with the expected export gives them a concrete way to check that agreement before the file generation is complete.

The administrator can see every record in the example report, so the export should contain those records. A user with limited access sees a smaller set, and their export should contain only that set. Those examples give the developer something to verify before completing the file generation.

Cucumber's Example Mapping guidance describes a way to capture rules, concrete examples and unanswered questions during the discussion of a story. It also separates new stories discovered in the conversation from the work already in scope.

If nobody knows whether the export should include archived records, the team needs an answer from whoever owns that rule. Recording the question and the work that depends on it lets the team decide whether to resolve it now or defer the affected work. The discussion can stay focused on decisions that change what the developer should build, with other questions left for when they affect the work.

A request for another export format would change the agreed work and needs a scope decision. Correcting the permissions remains part of the original feature, because the team had already agreed that the file must respect access restrictions.

Review the risky choice early

The choice of how to obtain the records deserves review before the rest of the export depends on it. If that approach fails to preserve the report's permissions, the developer needs to know while there is still little code to change.

A reviewer can assess that choice using the first coherent part of the export, its acceptance examples and relevant tests. The developer should explain which behavior follows the existing report and what remains unresolved, so the reviewer can examine the approach before more of the feature is built around it.

Google's guidance on small changes points out the wasted work when a large change reaches review and the reviewer finds that its direction is wrong. It recommends self-contained changes that include the context needed to understand them.

The reviewer needs to see how the export selects its records, with enough surrounding code to follow the decision. The team's code review practices still apply. Breaking the change into fragments that hide that behavior would make the decision harder to review.

Test beyond the file format

The export can have correct columns and delimiters and still return the wrong records. Its tests need to check the report's permission behavior while the feature is being developed, so the team can verify the requirement that caused the original correction.

A unit test could check a permission rule in isolation, while a test through the application checks the records that reach the exported file. If the results disagree, the team needs to trace the difference before extending the feature. Disabling the failed check or rerunning it until it passes would leave the discrepancy unexplained.

DORA's continuous integration guidance connects frequent integration and feedback with finding and fixing problems in smaller changes. It also acknowledges that completing a large feature on a branch can take less time than integrating it incrementally, while distinguishing that local completion from delivering reviewed and tested software.

The team can check each coherent increment of the export against the existing report during development. That gives the developer feedback about the permission behavior while there is still time to change the approach, before finishing the work that depends on it.

Measure the full cycle

Compare similar changes using the same starting and finishing events, including the time spent clarifying examples and checking the approach. A shorter implementation stage alone would not establish that the full development cycle became shorter.

Record why work returned to implementation so that a correction to misunderstood behavior can be distinguished from a new requirement or useful discovery. Review comments and revision rounds need context, since a thorough review may prevent a defect from reaching users.

In the hypothetical late-feedback sequence, the team builds the export, discovers the permission discrepancy during acceptance, corrects the implementation and repeats the checks. In the earlier-feedback sequence, the team makes the expected records explicit, checks the approach while it is small and develops the rest of the export using that feedback. The example shows where feedback would enter the work, but it contains no timing data from which to estimate a saving.

Keep a short record when trying this with a change in your own team.

  • Record the uncertain decision, such as which records the export may include.
  • Name the evidence needed, such as matching the permitted records in the report and the file.
  • Choose when to obtain that evidence, before expanding the data-selection approach.
  • Note whether the same misunderstanding caused a later return to implementation.

Follow problems discovered after deployment separately, because they fall outside the completed feature's cycle. DORA recommends reading delivery performance in context, with measures of throughput and instability together. A shorter cycle that is followed by more corrective work deserves investigation.

Choose a recent change that came back for correction and ask the people involved which information arrived late. Agree on how to obtain that information earlier in the next comparable change, then compare the full cycle and the work that followed delivery.