Using a Sprint Burndown Chart to Keep Your Product on Track

The perfect product launch is an elusive beast. As the launch date nears, the pressure mounts while the product manager deals with last-minute changes, bugs infesting the Jira board, and some network or server issue that threatens to ruin everything. You might have the perfect product management framework, yet the journey to the finish line is usually anything but elegant.

Whether you're launching a new product or releasing a new feature, product managers thrive on the excitement, exhilaration — and exhaustion! -— that come with the job, particularly surrounding significant releases. Even with careful planning, an exquisite product roadmap, and a neatly refined backlog, the final moments before launch always seem to end in a fight to the finish.

Before you place all the blame on your product management framework, or worse, your product team (Nah, you would never do that!), take a step back and breathe. We’ll walk through some ideas on how you can relieve some of the chaos on launch day. (Let's be honest, no drama on launch day would be just a little disappointing.)

Pre-launch planning

If you're using an agile product development methodology like Scrum or Kanban, you're already ahead of the game in terms of planning. Experienced PMs will have a roadmap with t-shirt sized epics and stories carefully laid out using established prioritization methods.

Based on your product strategy, you may choose to release new product features to production after each iteration. But sometimes, the product marketing plan requires a bigger splash. In this case, you can take advantage of press releases, major advertising events, or other high-visibility marketing opportunities.

Planning how you intend to release the product is as important as deciding what will be part of the release. Product development teams need to coordinate with product marketing to consider the following:

• Will you do a soft launch to a limited audience?
• Do you need to pre-release specific components to test pricing, marketing copy, or usability?
• Will you leave pre-releases in the wild until launch, or will you test for a specific time period and then pull them back?
• Do you have a hard date on which you must release (ex., Super Bowl Sunday), or is there some flexibility in the timing?

Answers to these questions drive the release strategy, which is then factored into your release plan and execution.

When it comes to determining what features to include in your product launch, you can choose from a variety of product management frameworks or use a hybrid approach and mix and match the methodologies to fit your situation.

The Kano model, AARRR (acquisition, activation, retention, referral, and revenue) theory, and OKRs (objectives and key results) all provide product management frameworks. These help product owners plan feature releases that align with the product vision and realize profitability objectives.

Remember: It's always a good idea to have a Plan B or even a Plan C to allow for unexpected events or issues that tend to rear their heads just before a launch. Atlassian has a great product launch template to get you started if you're working on your first release.

Launch day planning

A launch day checklist is your best friend on launch day. You might even want or need more than one list. A product launch has too many moving parts across too many teams for you to rely on memory alone. Your marketing, IT, and product teams will all play a role in the launch, performing necessary activities for their roles.

Particularly if this might be the first product launch in your startup, checklists help product teams think through details with clear heads well before launch day. The best plan is to ask each team to create their checklist and then meet as a group to align and coordinate each task's timing. Some launch day tasks are independent, ready to be tackled at any time. In contrast, others will be more time-sensitive or dependent on something else happening.

For teams with a few launches under your belt, these checklists hold the lessons learned from prior releases and, when updated after each launch, turn your team into a smooth-as-silk, product-launching machine.

Post-launch planning

As you know, a product launch is not the end game. Once the dust settles and everyone has gotten some sleep, you need to measure how the product performs. Planning how to measure the product’s initial key metrics allows product managers to communicate results to stakeholders early and as often as necessary.

Measuring key product metrics after a launch validates your decision-making of the product features, confirms you built the right product for the market, and helps you ask and answer the right questions when planning more feature builds and marketing strategies.

Important key product indicators following the launch can include total sales, top attribution channels, activation stats, and affinity sales. If you're launching a new feature within an existing product, you'll also want to keep an eye on retention numbers. A spike in churn rates could indicate a problem with the user experience or the underlying technology solution.

Beyond measuring the results of your release, you'll also need to prepare what's next. After your development team gets some shut-eye, they'll come back to work looking for their next assignment. You'll need to have your backlog ready for the next sprint planning ceremony, and then, it's back to business as usual. There may also be some immediate customer feedback that needs to be actioned.

Once you get your team off and running toward the next release, it’s time to take a look at your roadmap. You’ll likely discover new information when customers start using your new product or feature. It’s a good idea to leave some room in the roadmap to take on work discovered during the first few weeks of your launch.

Then there’s one last thing — CELEBRATE!! You and your team worked hard and accomplished something really cool! It’s easy to get caught up in the daily grind toward the next release. Take some time to pat yourselves on the back for a job well done.

Use your product management framework to tackle launch day like a rock star

With some planning and flexibility, you can set up your product team to make launch day look like a walk in the park. And the sooner you get good at this, the better. You'll always be launching something throughout the product lifecycle, from the initial MVP to new features to the end-of-life process.

Thorough roadmapping gets you off to a solid start, and as you get closer to launch day, you'll build out more of the critical details to ensure you don't miss anything. Cross-team coordination is essential, and checklists help open communication channels and get the entire team on the same page.

Early reporting on results builds confidence with stakeholders and is also a great way to show your team the results of their efforts.

Enjoy the adrenaline rush of launch day, but try to eliminate a little of the chaos and stress. As soon as you've launched, it's time to move on to the next thing. That's the nature of product development, and that's why we love it.

A product backlog represents all of the goals and desired outcomes within the development of a product. They are the specific tasks a team hopes to complete when they set out to design or improve upon a product.

What makes a product backlog so effective is its agile nature. Backlogs are in constant evolution, changing and adapting based on the current needs of stakeholders and customers. To keep a backlog up-to-date and in its most effective form, it needs to be continuously refined and adapted. This process takes time, but there are simple, powerful strategies for maintaining a quality backlog.

A good product backlog has four characteristics. It is:

• Detailed appropriately
• Estimated
• Emergent
• Prioritized

We’ll cover all of these attributes in detail, including how you can ensure your product backlog is in good health. But first, let’s get on the same page about product backlogs and the refinement process.

Transform your flat product backlog with

Easy Agile TeamRhythm

Try Now

What is a product backlog?

A product backlog is a prioritized and ordered list that represents the work to be completed by a development team. Backlog items are derived from the product roadmap and are organized based on the tasks that are most vital — the ones that will make the biggest impact at any given time.

Backlog items represent what it will take to develop a new product or improve an existing one with new features. It’s all of the work a team will tackle in the future, but it’s also a flexible, living organism that evolves as a development team learns more about the product and its stakeholders.

The product owner is in charge of ordering and prioritizing backlog items, placing high-priority items at the top. They are also responsible for backlog refinement, which ensures all backlog items are organized, have appropriate details, and are ready for any upcoming sprint planning.

Product backlogs vs. sprint backlogs

Sprint backlogs are quite similar to product backlogs, but they serve a different, more specific purpose. At the beginning of a Scrum, the product owner arranges the product backlog items that are to be completed by the Scrum team in that sprint.

The Scrum product backlog represents a small subset of the overall product backlog. The product backlog is the entire bottle of wine, while the sprint backlog is the glass of wine you’re going to tackle next. In this analogy, the Scrum master is the sommelier, providing guidance, context, and feedback throughout the sprint.

At the end of the sprint, a sprint review is conducted with the stakeholders to better understand what to tackle next. Backlog items that weren’t completed may be pushed back into the larger product backlog to get to at a later date or during the next sprint. Another sprint planning meeting will prepare the team to tackle the next batch of backlog items.

Why does a backlog need refinement?

Backlog refinement isn’t a luxury task reserved for when you get a chance to tidy up. Refinement is a key part of product backlog management that ensures a backlog always has the most recent, up-to-date information.

Refining the backlog prepares it for the development team, saving time in the long-run. The process helps to prioritize items and ensures there’s nothing in your backlog that you no longer need.

As you’re well aware, the agile methodology centers around flexibility and the ability to evolve a plan as new information or roadblocks appear. What you thought was important at the beginning of product development may not be necessary anymore, or your stakeholders may have turned you in a completely different direction.

Product backlog refinement includes:

• Adding detail to high-priority backlog items for greater comprehension.
• Improving and reviewing estimates.
• Removing items that are no longer relevant to the product.
• Adding items based on new stakeholder feedback.
• Making adjustments based on the most recent bug fixes.
• Prioritizing items that bring customer value.
• Ordering backlog items to deliver the most impact over the next sprint.

Backlog refinement takes time, but it’s well worth the effort to have a healthy, up-to-date backlog that’s always ready for the development team.

DEEP: The key attributes of a good product backlog

Roman Pichler, the author of Agile Product Management with Scrum: Creating Products That Customers Love, developed DEEP to describe the key attributes of a good product backlog. The acronym DEEP helps product owners and development teams understand how to make smart decisions while maintaining a successful backlog.

The concept is applied throughout the product backlog refinement process, which is a critical part of backlog management. Backlog refinement, previously called backlog grooming, is an ongoing process that ensures a backlog is in tip-top shape. We like to think of it like trimming the branches of a plant.

To help a plant grow, you need to prune and trim it. The refinement process adds details where needed and prioritizes items based on the current information a product owner has from team members and stakeholders.

DEEP stands for Detailed appropriately, Estimated, Emergent, and Prioritized.

Following these guidelines and best practices will lead to a quality backlog, which will lead to smooth product development and a successful end result. Let’s dig into each attribute. 🔎

Detailed appropriately

Details matter, especially as a user story rises in priority. As a backlog item gets closer to being completed or moved into a sprint backlog, it requires more detail. Upcoming backlog items should be detailed appropriately, so they can be better understood by the development team. The closer an item is to being completed, the more detail it should have.

On the other hand, items that are lower on the priority list don’t require nearly as much detail. It’s a poor use of time to add details to lower priority items since you never know how the backlog is going to evolve. You could waste a lot of time detailing low-priority items when they might be removed or revised later on in the process.

Estimated

Thorough estimation should be focused on high-priority items that will be tackled soon. As you refine your backlog and add more details to top-priority items, you can improve your estimation. A good option is using story points to zoom in on the details. They can help you accurately and practically reflect the reality of an item from the customer’s perspective.

📘 Read our guide to incorporating user story points to start using this technique.

Since not much is known about them, it’s difficult to properly estimate items that are lower in priority. When you are further down the priority list, your estimation will be more of a guess since you don’t have all of the information yet. In these cases, use a simple agile estimation technique, such as t-shirt sizing (labeling work items as XS, S, M, L, XL) to make a guesstimate. Based on the information you have at that moment in time, make an approximate estimate on the exertion required for that backlog item.

Emergent

The more you learn about the product and its customers, the more you can improve your product backlog. The backlog is a living document that represents your plan at any one given time. It’s not set in stone, and it should see revisions and improvements as you go.

With the information gleaned from retrospectives and stakeholder feedback, you can update the backlog to reflect what you’ve learned along the way. Allow your backlog to evolve, adding, removing, and refining items as needed.

Prioritized

A product backlog needs prioritization. Items at the top are a higher priority, and items toward the bottom are a lower priority. When deciding which items should be prioritized, consider the value each item will provide.

Your team can maximize its efforts by prioritizing the backlog items that will provide the most value to customers at any given time. Since this will change depending on the current needs of your customers, you need to continually adjust and refine your priority order.

Achieve a DEEP product backlog with Easy Agile

Easy Agile is dedicated to helping agile teams work more effectively. We have a suite of Jira apps designed for teams that want to develop products that put the customer at the forefront of decision making.

Easy Agile TeamRhythm transform your flat product backlog, prioritizing based on value to the customer and bringing the customer journey to life. They help teams organize and prioritize user stories while visualizing the customer journey. Keeping your customers embedded in your process will help you make refinement decisions that are in the best interest of the customer, no matter what phase of development you’re in.

Learn more about our agile apps and follow our blog for the latest content for Jira teams.