A two-week Sprint creates the impression that a Scrum Team learns every two weeks.
But that is true only if useful feedback reaches the team within that period.
A Sprint may end while the work is still awaiting integration, testing, deployment or use by real customers. The Scrum events continue, but the most important feedback arrives several Sprints later.
A timebox is not a feedback loop
The Sprint establishes a regular rhythm for inspection and adaptation. It does not determine how quickly the technical system produces evidence.
There may be several feedback loops within the development process:
- automated tests reveal whether the code behaves as expected
- integration reveals whether it works with the wider system
- stakeholder review reveals whether it addresses the intended need
- deployment reveals whether it works in its real environment
- customer use reveals whether it produces the hoped-for outcome
Each loop operates at a different speed.
If the Sprint lasts two weeks but software is released every eight weeks, the team may complete four Sprints before receiving feedback from real use:
8-week release cycle ÷ 2-week Sprints = 4 Sprints
That is not necessarily wrong. Some outcomes genuinely take time to emerge. But the team should not confuse frequent Sprint boundaries with frequent learning.
Slow feedback creates accumulated uncertainty
When meaningful feedback arrives later, the team continues making decisions based on assumptions that have not yet been tested.
- More code may be built upon an unsuitable design.
- More features may be added to something customers do not understand.
- More plans may depend upon an outcome that has not yet happened.
The work may appear to be progressing smoothly while uncertainty quietly accumulates.
Throughput can remain stable throughout. The Product Backlog can continue moving. Every Scrum event can take place on schedule.
Yet the team may still be several Sprints away from discovering whether its decisions were sound.
Map the real feedback loop
Choose a recently completed Product Backlog item and trace its journey.
Ask:
- When did development begin?
- When did the first automated test provide useful feedback?
- When was the change integrated with the wider product?
- When could stakeholders examine it?
- When was it deployed?
- When did someone use it in a real situation?
- When could the team observe whether it produced value?
The purpose is not to force every form of feedback inside the Sprint. It is to make delays visible and decide which of them can be reduced.
Possible improvements might include:
- dividing work into smaller, independently testable slices
- improving automated testing
- integrating changes more frequently
- making test environments available sooner
- reducing manual release steps
- improving production monitoring
- involving stakeholders earlier
Shorten the learning cycle
When feedback is too slow, the instinct may be to shorten the Sprint.
But a shorter Sprint does not automatically accelerate testing, integration, deployment or customer learning. It may simply create more frequent checkpoints within the same slow system.
Before changing the Sprint length, examine the development feedback loops surrounding it.
A shorter Sprint inside a slow learning system merely gives the team more opportunities to report that it still does not know.
Photo by Compagnons on Unsplash
