Scrum, day 29: finishing sooner

Today's objective: find a small, usable slice of a product change that can reach Done early enough to inform the remaining work.

Read alongside: Mastering Professional Scrum, chapter 3, focusing on getting Product Backlog items to Done earlier in the Sprint. Allow roughly five minutes for this companion, plus the assigned reading.

A busy week can still leave nothing to inspect

The fictional ShiftSwap team starts work on the manager handover flow. One Developer prepares the complete list design, another extends the service, and another plans all the verification scenarios. Each activity makes progress, but none produces a usable change on its own.

If everything comes together near the end of the Sprint, the team will have little time to respond to integration problems or misunderstandings. The risk is not necessarily that people work slowly. Their plan postpones the point at which the connected product can reveal whether their assumptions fit together.

The Developers ask whether one useful part of the flow could reach Done earlier, while preserving the Sprint Goal and the product's quality standard.

Slice by a user capability

The team considers “finish the database work first” as a small piece. It may be a useful implementation task, but it does not let a manager accomplish anything new. It also postpones the interface and interaction questions that could challenge the data assumptions.

A different slice lets a manager see the current pending requests for one café and open an individual request using the existing decision flow. It includes enough interface, service, permissions, and verification work to make that capability usable.

The scope is narrower than the complete handover improvement. It is still meaningful: a manager can find pending decisions without reconstructing them from messages. The team can inspect whether the information is understandable before adding conveniences and extending the behavior.

Keep the boundaries honest

A first slice for one café can make sense when the product can safely distinguish that café and preserve existing behavior elsewhere. It would not make sense if implementing it silently broke the second café or created inconsistent request states across shared components.

The Developers must understand the boundary technically and explain it in product terms. Elena needs to know who can use the capability, what remains unchanged, and what benefit it can provide. The slice should not depend on an unwritten assumption that everyone will avoid the unfinished paths.

Smaller scope does not justify weaker quality. The relevant product standard still applies to the slice. If it cannot be integrated or used safely until several other pieces are finished, the team has identified a dependency rather than achieved an early Increment.

Use an early result to answer a real question

Suppose the first slice reaches Done on the third day of the Sprint. A manager tries it with a few realistic requests and notices that the list shows the employee's name but not enough shift context to distinguish two similar requests.

That observation can inform the remaining work while the Developers are still shaping it. The team can examine a clearer description and verify whether it resolves the ambiguity. Discovering the issue at the Sprint Review would still be useful, but it would arrive after more decisions had been made around the incomplete understanding.

The example does not prove that early delivery always saves time. It illustrates a specific opportunity: shorten the distance between an assumption and an observation that can change the plan.

Distinguish Done from an incomplete preview

A sketch or prototype can also generate useful feedback. The team should describe it accurately. A manager reacting to a simulated list is providing evidence about that representation, not demonstrating that the integrated product works.

Scrum.org's Increment reference explains that an Increment must be usable, work with prior Increments, and meet the Definition of Done. Several can be created during a Sprint, and delivery need not wait for the Sprint Review.

ShiftSwap may choose a sketch when it needs inexpensive feedback on a concept. It may choose an early Done slice when it needs evidence from connected behavior. Both can support learning if the team remains clear about what each result establishes and what it leaves untested.

Plan for completion across skills

To finish the pending-list slice early, the Developers coordinate around that result. The colleague shaping the interface works with the service Developer on the relevant examples. Verification begins as behavior becomes available, and integration is part of the plan from the start.

This arrangement may mean fewer unrelated tasks are started immediately. Someone who could begin a later filter feature instead helps resolve a permission question for the first slice. The short-term appearance of individual busyness may change while the team improves its chance of completing a usable result.

The Developers should still use judgment. Five people crowding around a task that two can handle effectively would not help. They can contribute in different ways, including preparing relevant examples, investigating a dependency, or making the next slice clearer.

Avoid slices that manufacture misleading progress

Breaking one feature into twenty tiny tickets does not automatically create twenty useful Increments. Some tickets may represent internal steps that have value only when combined. Counting them as separate product achievements would distort the picture.

The team can keep implementation tasks where they help organize work while identifying the smallest connected capability that matters to a user or stakeholder. It should also avoid cutting an item so narrowly that its integration and coordination overhead overwhelms the benefit of finishing sooner.

The useful size is contextual. A good slice is small enough to finish and inspect, coherent enough to use, and substantial enough to inform a meaningful next decision.

Find your next finishable slice

Choose a broad item currently in progress or near the top of the Product Backlog. Describe the user capability it aims to create. Then propose a narrower version by limiting one meaningful dimension, such as a supported scenario, user group, or optional convenience.

List everything needed for that narrower version to meet the Definition of Done. Look for dependencies that would make it unusable on its own. Explain what someone could do with it and what observation could influence the remaining work.

Finally, adjust the delivery plan so the slice can finish before the rest. A smaller item offers little benefit if the team still waits until the final day to integrate and verify it.

Reflection: what could your team learn from a usable result this week that a collection of partially completed tasks cannot yet tell you?

Next, day 30 examines what to stop starting so that useful work can finish.