9. Plan the sprint and kick off the agile cycle

Lean is the “brain” in the agile process Agile on its own is good at managing the delivery of working code at the end of every sprint, but it does not help you ensure that you’re building the right thing or solving the right problem. That is where lean comes in and acts as the “brain” on the agile process: Everything you do or build in a sprint is an experiment — with the focus on learning whether the thing you are building gets you the outcome you were expecting. Therefore, your user stories take the form of hypotheses. At the end of each sprint, the team reflects on what it learned, makes an adjustment, and starts a new experiment. The team and client must be willing to adjust, pivot, or discard, or it isn’t really an experiment.

Your turn: Conduct the following steps during each agile sprint:
For more in-depth reading on 18F’s Agile principles & practices, see this guide.

Just before the beginning of the sprint:

1. Groom the backlog

Who: Product owner, project lead, team optional.
What: Order hypotheses (stories) by priority in the appropriate backlog.

At the beginning of the sprint:

2. Plan the sprint

Who: All! (PO/PM/Team)
What: Bring stories into the sprint backlog. Team defines and volunteers for tasks, and write acceptance criteria (for example user outcomes, basic functionality).

3. Hold a design studio

Who: All! Including PO. Everyone must sketch. What: Design studios are a means to iterate through ideas, allow the entire team to have input into potential solutions, build shared understanding, and break down hypotheses.

During the sprint:

4. Build. As work starts on tasks in the sprint backlog, move them to a “working” list. When they’re completed, move them to the “acceptance testing” list, to indicate that the story is ready for acceptance by the product owner. In lean UX, we try to define acceptance criteria for a story as a mix of both basic functionality (the thing “works”) as well as the desired outcomes for the user (for example “Users X are able to easily export data into their workflow).  

Work in progress during a sprint

5. Research: As the features that test each story are built, get out of the building and test them with users.

Who: Include team, POs whenever possible.
What: Conduct sprint user research that simultaneously tests against desired outcomes from current sprint hypotheses and explores questions necessary for future sprints. Check out some of our design method cards for a variety of ways to evaluate your product’s features with users.
It may be helpful to create a separate Trello board (or document) for capturing — and easily sharing — user research findings. Here’s one example:

Example of how to capture user research in trello, in a hypothesis format

At the end of the sprint:

6. Synthesize the results of user research with the team.

Who: Include team, POs whenever possible.
What: Ask everyone what did we learn? Do we need to adjust? As insights and new ideas come about, put them into the “story candidates backlog,” so they can be prioritized in a future sprint.
Tip: To keep track of story candidates that arise from research, it may be helpful to use color labeling, or create a second list of research-driven story candidates in your main project board, like this:

Example of how to integrate hypotheses from user research findings into your project board

7. Hold a sprint review

Who: The whole team, and any stakeholders who would like to observe. What: Demo the completed stories, and review the key sprint findings: What was learned? What hypotheses were proved or disproved?  What will we try next?

What’s next?

Based on what the team learned learned, you may need to come up with new or different hypotheses about how to go about getting the desired outcome. Or, if you’ve achieved your desired outcomes, you may move on to the next set of priority stories in the backlog to tackle. Repeat the sprint cycle, always with the focus on learning.

As the project progresses, its the job of the project lead and product owner to also make sure that the focused hypotheses of the sprint are feeding back up and informing the broad outcomes and goals for the project.