Scrum, day 03: build something usable, then learn

Today's objective: propose a small usable product change and distinguish the capability it adds from an improvement informed by feedback.

Read alongside: Scrum: A Pocket Guide, fourth edition, §1.4, “The iterative-incremental continuum.” Then read the Increment section of the Scrum Guide. Allow roughly four minutes for this companion, plus the assigned reading.

Choose a small result a person can use

The fictional ShiftSwap team has decided to make shift exchange status clear. It could organize the work as a sequence of technical components: database changes, an API, interface screens, and tests.

Each component may be necessary, but a manager cannot approve a swap with a database migration alone. An employee cannot rely on a screen that displays a simulated status. To learn how the feature works for those people, the team needs the relevant pieces to function together.

It describes a small result in user terms:

At one café, an employee can invite an eligible colleague to cover a shift, the manager can approve the arrangement, and both employees can see whether it is final.

That sentence narrows the audience and capability while retaining a meaningful flow. Supporting every café, building automatic recommendations, and adding a dashboard can be considered separately. The first flow still needs to handle its own rules and important failure cases.

Compare three possible slices

Consider three ways the team could finish its first batch of work.

All three may be useful during development. Be precise about what each result supports. Feedback about a simulated screen cannot establish the reliability of the final service. Successful API checks cannot establish that employees understand the outcome.

The Scrum Guide requires an Increment to be usable, to work with previous Increments, and to meet the Definition of Done. It also allows delivery before the Sprint ends. A prototype or an isolated component does not automatically satisfy those conditions.

Add a capability, then improve it

The first working flow adds a capability to ShiftSwap. Employees can now arrange a particular kind of exchange through the application. That is the incremental aspect of the work: the usable product has gained something.

The team then observes the pilot. Suppose employees often reopen a request because the status “accepted” seems final even when managerial approval is pending. The team changes the wording, makes the pending step visible, and checks the result with users again.

That is an iteration on the existing capability. The team is revisiting a design decision using feedback. Later it might add support for inviting a second colleague if the first invitation is declined, then improve that behavior as well.

These ideas work together. The team can add a modest capability and improve it through several rounds of learning. The size of the feature, the size of a code change, and the length of a Sprint describe different things; one should not be assumed to determine all the others.

Keep the small version dependable

During planning, someone proposes omitting authorization checks from the pilot to save time. The team instead reduces the scope to one café and a simpler approval policy. It retains the checks needed for that flow.

For this fictional product, useful completion criteria might include the following:

• Only the relevant employees and authorized manager can access the request.
• Two competing actions cannot produce contradictory final arrangements.
• The visible status matches the stored result, including after a page reload.
• Important transitions have automated checks and have been examined in the integrated product.

These are examples of product-specific concerns, not a complete Definition of Done. The team would need a shared quality standard appropriate to the product and its environment. Item-specific acceptance criteria describe the particular behavior being added; the Definition of Done supplies the common quality boundary. A later companion will examine that distinction in more detail.

Make the next decision explicit

A usable change creates an opportunity to learn. It does not guarantee that learning will happen.

Before the pilot, the team decides which questions it wants to answer. Can an employee identify the final status without help? Can the manager resolve pending requests reliably? What happens when an invitation is declined?

The resulting observations inform the next choice. If the basic flow remains confusing, expanding it to more locations may amplify the problem. If it works well for the pilot group, the team can investigate what differs at another café. Either decision should acknowledge the evidence's limits.

Releasing this small flow also needs an appropriate operational decision. Usability and quality make release possible; the team still needs to consider whether this audience, timing, and support arrangement are suitable.

Try slicing a feature

Choose a feature you know and describe the smallest result that a particular person could use from beginning to end. Name one audience or scenario you can leave for later, one quality requirement you must preserve, and one observation that would influence the next change.

Then describe two subsequent steps: one that adds a capability and one that improves what already exists.

Reflection: if your proposed result is finished tomorrow, who can actually use it, and what can they complete? If the answer is unclear, revisit the boundary of the work.

The next companion explores how to plan when useful information will continue arriving during delivery.