How I use release markers to prioritize a backlog and communicate with my team

An example of my backlog and release strategy

Heddy Stern
· 3 min read

Many teams use releases to define a moment in time when a sprint might end, to signify a deadline, or to communicate a feature milestone. I tend to stay away from date-focused release markers because a prioritized backlog is always working on the most important story first, regardless of when that item might be due.

Instead, I like to use release markers as a prioritization tool and a communication tool. They help me gut check that the stories are optimally organized, make sure I am thinking small and lean, and tell the product story to stakeholders and teammates.

As a Product Manager at Pivotal Labs, I use Pivotal Tracker to organize a backlog, but obviously, these strategies can be used with any backlog tool.


Releases as a prioritization tool

Step 1: Set up

First, I create a draft of the backlog without any releases. Then, I add release markers based on my goals and my key performance indicators (KPIs).

Step 2: Prioritize

I use the release markers to re-organize the user stories in a way that ensures I’m meeting my goals with the existing features.

Step 3: Release Earlier

In order to release a lean product, I check to see where I could make the product leaner and meet the releases sooner. For example, Jane could organize by date before organizing the photos according to a folder naming convention, so I can move that release marker sooner, release the feature earlier, and measure it’s success faster.

I’ve managed to turn 5-story first release into 3 story release, which will help me get feedback faster.e


A Communication tool

An organized backlog tells the product story. It outlines the product goals, assumed lean iterations, and baseline priorities that will build out the product. This is valuable for stakeholders and teammates.

On a recent project I was struggling to connect with and communicate with a specific stakeholder around product priorities. The stakeholder wanted to know when the ‘MVP’ would be ready and I wanted find ways to communicate around iterative releases. After sharing a re-formatted backlog with clear, business-value based release markers, the stakeholder was to internalize our plan and product goals. This meant they stopped asking when the MVP would be ready even though we didn’t give them an exact release date. This happens when stakeholders can transparently check on, understand, and influence the priorities in the backlog at any time.

The release markers also help the engineers and designers understand the larger business goals associated with the product we’re building. When leading a sprint planning meeting (or IPM at Pivotal), I use the upcoming release markers to communicate to the team where we’re going, and then look at each story individually as it builds to a release.

This ultimately helps both the team and the stakeholders understand the product direction. The organization surfaces reasons to change direction faster. Finally, it motivates the team by showing why the product we are building matters.


Pivotal Labs is an lean + agile software consultancy. We collaboratively build and design mobile and web apps for the world’s largest brands.

If you’d like to learn more, please visit our careers page.


Product Labs

Product and Design advice and stories from the folks at Pivotal Labs

Heddy Stern

Written by

Associate Director @PivotalLabs in Boston

Product Labs

Product and Design advice and stories from the folks at Pivotal Labs

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade