How I use release markers to prioritize a backlog and communicate with my team
An example of my backlog and release strategy
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.
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.
Other pieces about Backlog Management: