“Stories” Don’t Tell a Story: Good Sprint Planning Uses Milestones

In too many engineering teams, sprint planning and daily standup are centered on the sprint board and backlog. Stories (tasks) are the focus of attention; discussions are focused on achieving pointing targets, the mechanics of how to achieve a particular task, or dependencies and sequencing. The problem is that teams lose sight of the forest for the trees. We forget that stories are only a crude approximation of the work needed to finish an initiative; and more importantly, that the work only matters when it has delivered end value.

Teams lose sight of the forest for the trees

Teams that only pay attention to their story backlog will find it difficult to relate their work to the company’s roadmap. Managers will often find themselves in the tough situation of not being able to look at the sprint board and know with confidence when a project will be done, because the board doesn’t translate to shipping. Also, story planning often overlooks the “glue” steps and the last mile of release and polish.

To use a Lego analogy: it’s as if in January we agree on the fabulous model we want to build; we estimate the number of Lego blocks we’ll need and put those in a big pile; and then we start frantically assembling in hopes that it will all add up by March.

In this post I will argue that engineering teams can make a subtle but invaluable shift in how they think about sprint planning, such that milestones (near term goals) lead the conversation during sprint planning. Stories are still useful for estimates and coordinating work, but they’re a tool, not the point.

“Stories” Don’t Tell a Story

A pile of sprint stories will never add up to the original initiative. If a team believes its job is to churn through stories, then it lays a heavy burden on someone else (usually the PM) to fill in all the gaps and adapt to changes — and very often, the result is that projects are left in an “almost-done” state for far too long. When sprint planning meetings are just about moving items from a backlog, the message is “it had been decided that we will do THIS WORK.” It will be hard to say when a feature will ship because of ALL THE OTHER WORK.

Milestones

Compare that to a narrative that leads with purpose: “we want to do THIS THING, so that’s why we think we should do THIS WORK.” The message is: “focus on finishing THIS THING.” It’s everyone’s job to fill in the gaps. They know they should reject unrelated tasks, or feel free to make reasonable adjustments. There should be a good sense of the overall project status.

Present sprint goals as a sequence of milestones, which are units of delivered value. These can be explained simply to both an internal engineering audience and also external stakeholders. The milestone is the hill you’re asking the team to climb; and when they’re at the top, they can celebrate the win and set their sights on the next hill.

What About Epics? Aren’t Those the Same Thing?

Done correctly, an epic is a milestone — it should be a deliverable goal associated with a collection of stories. However, in practice, epics are one of the most abused aspects of agile because people don’t treat epics as goals, they treat them as execution plans. During sprint planning, most teams just use epics as a project management mechanism to filter a sprint board or show Gannt-chart-like-progress. So what if 5 of 8 stories stories in the epic are complete — does that actually mean we are 63% of the way to delivering value? Probably not, there are bound to be a few extra steps; but the epic presented a false sense of specificity.

I especially blame Jira’s UI for ruining epics, by making them about projects and not products.

To avoid ambiguity, I use “milestones” to refer to goal-based planning, and “epics” as the mechanics of project management around these goals.

Manage Through Milestones

It takes surprisingly little additional work to shift to managing teams with milestones, and it makes a world of difference.

As a manager, I maintain a living Google document that lists our current milestones as handful of bullet points; and also, I have separate section of future milestones, to assure stakeholders that I’m tracking their needs. Each bullet point describes the value we intend to deliver; which larger project this relates to; and perhaps alludes to some of the specific tasks. For example:

Integrate with Sendgrid and use this to send our templated welcome email. This sets the stage for moving all emails to a more reliable delivery partner, and for marketing to be able to edit email templates in a self-serve fashion. We will get Sendgrid working in development and production; decide how templating will work; and design our first template.

Each sprint, my product partner and I review the milestones and re-prioritize as necessary. We often pull stakeholders into these conversations, which helps them feel more involved with the engineering process.

Sprint planning begins with discussing our milestones so everyone knows the “why.” Then we’ll build a sprint board around the stories that support those goals. It is important to do the breakdown into small tasks for the sake of realistically sizing work, and also for encouraging folks to call out missing details or to suggest better ways to reach a goal. The important thing is that we only thoughtfully include stories that support our milestones, rather than letting the backlog dictate our work. It’s also worth calling out that keeping the system up and running is a key goal too, and should be accounted for! Sprint planning should end with us agreeing on a realistic expectation of how far we’ll get towards our milestones by the end of the sprint.

Once the the end of the sprint rolls around, we should evaluate the actual progress against the original expectation. We use this as data to recalibrate our estimates for the next sprint, as well as to communicate to stakeholders the status update. Having this kind of constant visibility and feedback builds trust and confidence.

As a final point, running sprints mechanically against a backlog loses the narrative of why are we here? We humans are story-tellers, but so-called sprint stories (ironically) fail to inspire us this way. When people are focused on the goal and see tasks as directional and partial rather than absolute and complete, they will be empowered and motivated to deliver value instead of just doing the work.

If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.

— Antoine de Saint-Exupéry