Getting The "Plan" In Sprint Planning

About 18 months ago, while I was still dragging myself out of a COVID bunker/torpor, this passage in the Scrum Guide on Sprint Planning caught my eye:

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. [emphasis mine]

I realized, with some embarrassment, that the teams I serve and coach weren't really planning. Sure, we listed the work we intended to do, and sometimes decomposed it into smaller items. And sometimes we would assign those items to individuals based on a vague, "seems about right" notion of capacity, or even a calculated one. But that resulting list, event with people assigned to tasks, seemed like a poor excuse for a plan.

So I tried an experiment. In the following Sprint Planning one of my teams created a visual "map" of the sprint in a virtual whiteboard app (Miro, in this case). Starting with a 2-week horizontal timeline, we drew out which items we'd start with, how we'd collaborate to create solutions and move them to different environments. The discussion produced some valuable details, like who would need help from whom along the way, both inside and outside the team.

Below is the artifact of one such session with a team of three developers. They planned a 2-week sprint (thus the 10-square timeline along the bottom with a green mark for the weekend half-way through). Their goal was to create a web form that would enable users to upload a specific dataset with some metadata to a database. Creating this visual plan took about 20 minutes.

Each sprint backlog item supporting their goal is represented by a green square. The yellow squares are for supporting activities. The team also decided to fix a bug, which gets a red square. Note the outside expert (with halo) joining to test the product in a DEV environment on the Wednesday of week 1.

After mapping out the items and drawing lines for their expected durations, we noticed that there were three "checkpoints" in the plan: if we reached those moments and all was not well, we would likely need to rethink the remainder of the plan. So the team marked Daily Scrum on Wednesday and Friday of week 1 and Wednesday of week 2.

As it happened, all did not go well. In the Daily Scrum on Friday of week 1, the team observed that back-end work had taken longer than expected, and the form could not yet save data. They amended the plan as shown below, and re-negotiated scope by sending Form Validation back to the backlog.

You may be thinking "gosh, that looks like a Gantt chart." Well, that's true. My teams now create a Gantt chart for every sprint.

Before any of my fellow agilists clutch their pearls at the mention of the G-word, let me note an important caveat: this Visual Plan is not a heavy change-denial device or fantasy like the ones we're warned about in Scrum Master certification. It was created by, and for, the team itself. At no point do we pretend that the Visual Plan represents what will happen; rather, it's a visualized hypothesis, a tool for enhancing the feedback cycles built into the Scrum framework.

For example, at each Daily Scrum the team examines their plan and their progress so far to create, as the Scrum Guide puts it, "an actionable plan for the next day of work." By seeing where they've been, where they are, and what we think it to come (based on what we know now), they can make more informed, responsive, and responsible choices about commitments and renegotiate scope if necessary. In the Retrospective the Visual Plan becomes a useful artifact for remembering past events, experiences, situations, conflicts, etc. And, as implied above, the Visual Plan makes Sprint Planning more effective by helping the team commit more responsibly, "stress-test" their plans, explore "what if" scenarios, think through opportunities, conflicts, and dependencies in advance, and better own the work.

I've now tried this method with over 10 teams in the last year, and observed it consistently improves collaboration, team ownership, value delivery, and communication, both within the team and with stakeholders. Having a visual artifact to represent a real plan provides a shortcut to alignment, and keeps developers focused on the flow of value, as opposed to keeping busy.

Here are my usual steps, as a Scrum Master, for leading a team through creating a Visual Plan. Note, this comes after agreeing on a valuable Sprint Goal and pulling in/refining backlog items (per the Guide):

1. Ask "what will we do first?" and add those items to the timeline
2. Ask "how long with this [item]" take?
3. Poke a bit at how the team will deliver - are there collaboration opportunities here? Any dependencies or potential blockers? How will the item be tested/deployed? Who will do/coordinate these things? Represent the results somehow - with arrows, emojis, get creative!
4. Having mapped out the team's "first bite," continue steps 1-3 with later items until you have reached the end of the sprint.
5. Now step back and look at the whole and look for key moments or weak spots. What has to go well for this plan to work? Where's the biggest risk in this plan? If you find a risk, ask "how can we manage that risk?" Note key checkpoints in the plan when the team will inspect the current state.
6. Poll the team (I use "fist of five") about their confidence in the plan. If I see all 5s, perhaps we're not taking on enough risk and should consider a more aggressive plan. If I see many 3s or lower, I ask "what would need to change to make those [3s, 2s] into 4s?"

Give it a try, and remember: a list is not a plan.

#scrum #scrummaster #agilecoach #agile #sprintplanning