“Stories” Don’t Tell a Story: Good Sprint Planning Uses Milestones
By: Chuck Groom
Tags: Product Management, Sdlc, Leadership, Engineering Mangement, Agile Methodology

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.