Scrum, day 53: designing a useful pilot

Today's objective: choose a bounded pilot that can produce useful product evidence and reveal the conditions needed for a larger adoption decision.

Read alongside: Software in 30 Days, chapter 3. Use the chapter to examine your proposed pilot, while checking framework terminology against the current Scrum Guide. Allow roughly five minutes for this companion, plus the book reading.

Make the pilot answer a question

The fictional organization behind ShiftSwap wants to try a more empirical approach to a new café rollout. It could choose a trivial internal task, declare success after holding the events, and announce wider adoption. That would reveal little about its ability to deliver useful product changes.

It could also choose its most urgent, entangled initiative with no room to adjust expectations. That setting might expose many problems at once while making it difficult to learn safely from the trial.

A useful pilot sits between those extremes. It should matter enough to require real collaboration and product judgment, while remaining bounded enough that the organization can inspect the result and choose what to do next.

Select a coherent product problem

The organization chooses to help one additional café manage a clearly defined set of eligible swaps. Employees and managers are available to collaborate, and the existing ShiftSwap product provides a starting point.

The scope includes a usable flow rather than isolated technical tasks. It also exposes relevant uncertainty: the café's operating practices may differ from those already supported. The team will need to learn and adapt rather than merely execute a known installation checklist.

The pilot should have an understandable product boundary. If it combines unrelated requests from several departments, success may become difficult to define and the team's attention may fragment before it creates a coherent result.

Provide the conditions for a fair trial

The organization identifies a Product Owner with real decision authority, Developers with the relevant skills, and Scrum Master support. It protects enough availability for the people to work together and provides access to the environments and stakeholders they need.

Calling a collection of part-time contributors a team does not ensure those conditions. If every person is redirected by a different manager, the pilot may primarily test how much interference a group can absorb.

The organization should make its support commitments explicit. That includes how competing requests will be handled and who can resolve constraints beyond the team's authority.

Define the learning and the product result

The pilot has two related questions. Can the team create a usable swap flow for the café? Does working through short cycles of inspection and adaptation reveal consequential differences early enough to improve decisions?

The first concerns the product. The second concerns the working approach. A technically successful release with no adaptation may offer limited evidence about the second question. An informative workshop without a usable product result may leave the first unanswered.

The organization should inspect both, without demanding that every observation prove the approach successful. A trial can reveal that a necessary condition is missing or that the selected scope needs revision.

Establish a starting point and review conditions

Before beginning, the team records the current workflow, important known difficulties, and the organization's usual way of discovering and responding to surprises. It keeps the record modest and concrete.

The organization agrees when to inspect the pilot and which decisions will follow. It might continue with another useful slice, address a revealed constraint, expand participation, or stop pursuing the current opportunity.

The review point should not imply that all uncertainty will be resolved by a particular day. It creates an opportunity to use the evidence available. The book's title is not a guarantee that any product or organizational change can be completed in thirty days.

Keep costs and safeguards visible

Even a small pilot uses people's time and may affect real users. The organization should account for learning, support, verification, and operational preparation. “Pilot” does not mean quality requirements disappear.

The team can limit exposure through a clear supported scope, an appropriate rollout arrangement, and a dependable fallback where needed. It should explain what users can rely on and what remains outside the trial.

These choices should be proportionate to the actual product consequence. The aim is to create credible evidence from real work without pretending that a limited experiment is free of cost or responsibility.

Avoid preparing a success story in advance

If the pilot team is told that the organization has already committed to a full rollout regardless of the result, the evaluation loses much of its purpose. People may feel pressure to hide difficulties or describe ordinary progress as exceptional.

The sponsor should invite an account of what worked, what did not, what conditions mattered, and what remains uncertain. Evidence that challenges the expansion plan is valuable if it prevents a larger mistaken commitment.

Likewise, exceptional support during the pilot should be recorded. A team with immediate access to every decision-maker may perform differently when the same support is spread across many teams.

Sketch your pilot

Describe the product problem, users, supported scope, team, and required organizational support. State one product outcome and one learning question about the working approach.

Identify the evidence to collect, the important costs or constraints, and the decisions available at the review point. Include one condition that would make the pilot an unfair test and explain how you would address it before beginning.

Reflection: if the pilot went well, what would you still need to know before assuming the result could be repeated elsewhere?

Next, day 54 examines what a sponsor can do beyond endorsing the pilot.