post

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Successful product management in companies where it’s least understood

Measuring critical user journeys – Javier Andrés Bargas-Avila (UX Director, Google)

A new way to look at applied experiments

Product survey findings: Only 15% of users are embracing AI features 

Building high-performing product teams: The PDLC approach

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Overcoming the 20% feature usage challenge

Product Management

Three product leaders to learn from at #mtpcon inside Pendomonium

Victor Conesa is Product Manager at Justinmind, www.justinmind.com, where he uses his business, tech and UX experience to refine and promote Justinmind's interactive prototyping tool.

Victor Conesa

<p><strong><em>Or Three Ways Product Owners can Stay on top of Scrum</em></strong></p>
<p>2016 was a big year for the Justinmind product development team. We shipped a new feature every month or so, tackled bug fixes and upgraded the usability of our software (an interactive prototyping tool). With hindsight it was exciting, but such intense activity presents challenges for a product owner: backlogs can get baggy and prioritization between user stories can become complex. Failure to get on top of a growing backlog can result in creeping product instabilities. I thought it was time to start managing Justinmind’s product backlog more effectively.</p>
<h2><strong>The Challenges of Backlog Grooming</strong></h2>
<p>In theory the product backlog-sprint relationship is simple: you prioritize user stories in the Product backlog and, when a new sprint rolls around, pull the top priorities into the sprint and let the team get to work.</p>
<p>In practice though, there are complicating factors. In smaller teams it’s difficult to do everything you would like or need to do in a two-week sprint &#8211; and it’s impossible to go into a detailed cost-benefit analysis of every task, every fortnight. Most saliently, it can sometimes feel like the Scrum methodology creates imbalanced sprint workflows: <strong>prioritizing major product changes against small tweaks becomes impossible with everything piled together in the backlog</strong>. With no separation between categories of user story, there’s a risk that Product Owners can start to avoid heavy new feature stories and just focus on the low-hanging bug fixes, or vice versa.</p>
<p>At Justinmind we felt like we were comparing apples with oranges and ending up with problems, so we explored ways to improve our backlog management</p>
<h2><strong>Mini-backlogs, More Organization</strong></h2>
<p>As product owner, I came up with a system for managing backlog activities that was agile enough to work for a small product team, but also rigorous and objective enough to ship large-scale features regularly. My system revolves around categorizing user stories into related groups using color-coded JIRA filters, which allows user stories to be filtered by priority within their category.</p>
<figure id="attachment_10709" aria-describedby="caption-attachment-10709" style="width: 567px" class="wp-caption alignnone"><a href="//wp-content/uploads/2017/03/Justinmind-Backlog-Mockup.png"><img loading="lazy" decoding="async" class="wp-image-10709" src="//wp-content/uploads/2017/03/Justinmind-Backlog-Mockup-300x187.png" alt="Justinmind Backlog Mockup" width="567" height="353" srcset="/wp-content/uploads/2017/03/Justinmind-Backlog-Mockup-300x187.png 300w, /wp-content/uploads/2017/03/Justinmind-Backlog-Mockup.png 701w" sizes="(max-width: 567px) 100vw, 567px" /></a><figcaption id="caption-attachment-10709" class="wp-caption-text">Mocked up image of Justinmind’s unfiltered backlog</figcaption></figure>
<p>Say I want to manage UX Improvements stories in the backlog. I click the blue tab at the top of main backlog and all other stories are filtered out. Now it’s easier to prioritize these stories because like is compared with like. I can manage this mini-backlog by putting priority features at the top, before moving on to the next mini-backlog and doing the same.</p>
<figure id="attachment_10710" aria-describedby="caption-attachment-10710" style="width: 535px" class="wp-caption alignnone"><a href="//wp-content/uploads/2017/03/Justinmind-UX-Improvements-Mockup.png"><img loading="lazy" decoding="async" class="wp-image-10710" src="//wp-content/uploads/2017/03/Justinmind-UX-Improvements-Mockup-300x198.png" alt="Justinmind UX Improvements Mockup" width="535" height="353" srcset="/wp-content/uploads/2017/03/Justinmind-UX-Improvements-Mockup-300x198.png 300w, /wp-content/uploads/2017/03/Justinmind-UX-Improvements-Mockup.png 701w" sizes="(max-width: 535px) 100vw, 535px" /></a><figcaption id="caption-attachment-10710" class="wp-caption-text">Mocked up image of the UX Improvements filter in action.</figcaption></figure>
<p>Within each filtered section, we use a scoring system to determine task difficulty. Like any scoring system, it has to be fast to implement (no one wants to spend more time scoring stories that working on them) and transparent to product stakeholders. <a href="https://www.justinmind.com/blog/agile-scrum-planning-made-fun/">Scrum poker works for us</a>: the team estimates each task in the backlog according to a points system &#8211; 1 for easy up to 16 for epics &#8211; using personalized Scrum cards, a relaxed yet focused approach that encourages honest discussion and more efficient story estimation.</p>
<figure id="attachment_10711" aria-describedby="caption-attachment-10711" style="width: 532px" class="wp-caption alignnone"><a href="//wp-content/uploads/2017/03/Justinmind-Sprint-Mockup.png"><img loading="lazy" decoding="async" class="wp-image-10711" src="//wp-content/uploads/2017/03/Justinmind-Sprint-Mockup-300x220.png" alt="Justinmind Sprint Mockup" width="532" height="390" srcset="/wp-content/uploads/2017/03/Justinmind-Sprint-Mockup-300x220.png 300w, /wp-content/uploads/2017/03/Justinmind-Sprint-Mockup.png 701w" sizes="(max-width: 532px) 100vw, 532px" /></a><figcaption id="caption-attachment-10711" class="wp-caption-text">Mocked up image of Justinmind’s Sprint. You can see the points valuation for each story on the right</figcaption></figure>
<p>When the time comes to build a sprint, I go into each mini-backlog and harvest the top two or three user stories, adding them to the sprint. Justinmind’s sprints usually contain stories that add up to 35 points: based on past experience and team size, this is a realistic sprint workload for us. Bigger teams or teams with different capabilities will have different points capacity.</p>
<h2><strong>Split Backlogs, Split Roadmaps</strong></h2>
<p>Justinmind’s product team is pretty small, so the mini-backlog system described above works nicely for us right now. However, in a bigger scrum team with more user stories, the mini-backlog system can be extended into splitting your product backlog in two. On one side would be ongoing tasks, including bugs and improvements to features, on the other side anything new, such as features. The big new features and product lines should be prioritized in detail using a scoring system, whereas as the ongoing tasks (which are likely to be repetitive and familiar in scope) can be dealt with more loosely and analyzed less meticulously. This frees up product owners to focus on large new tasks while still pro-actively managing stories.</p>
<p>For some agile teams, splitting user stories into two separate roadmaps might mean <a href="http://apetro.ghost.io/big-vs-small-product-owner/">dividing out the product owner’s responsibilities between two new roles, say product backlog manager and product owner</a>, as Andrew Petro argues. While this isn’t mandatory, it is another solution for when the product backlog starts to sprawl.</p>
<h2><strong>Velocity Tracking</strong></h2>
<p>Another option for product backlog management is to track a team’s velocity, or how much work gets done in a sprint. Once the product owner has tracked velocity over a few sprints and collected some averages, this data can be used to forecast how many stories and of what type can be added to future sprints.</p>
<p>Calculating velocity is simple. In a two-week sprint, the product team delivers stories with a combined value of 35, making that sprint’s velocity 35. The next sprint they deliver stories with a value of 20. The average velocity is, therefore, 27.5. Anything your team counts in story points, including bugs and tweaks, can impact velocity estimation; incomplete stories don’t count towards velocity, sorry.</p>
<p>For our team, we tracked our velocity to be about 35 user story points a month. Every time I build a sprint, I add stories that have been evaluated in scrum poker by the scrum team, and try not to exceed 35 points. I keep an eye on the velocity average once in a while, to make sure we’re working as we should be.</p>
<p>Such long-term velocity tracking allows product managers to estimate how long they’ll take to work through their current backlog, and justify this estimation empirically to teams and stakeholders.</p>
<p>The great part about velocity tracking is, the more you do it the better you get. The greater your data on team capacity and performance, the more accurate your backlog management will be.</p>
<h2><strong>Pro-active Backlog Management: The Benefits</strong></h2>
<p>Mini-backlogs help you to stay organized because they allow you to compare like with like when prioritizing tasks, and they help maintain a varied spread of activities in each sprint. Additionally, it’s not the end of the world if the scrum team hasn’t evaluated the difficulty of each story before the sprint is built, because they’re already organized by priority.</p>
<p>On a deeper level, we found that breaking the main backlog into sections resulted in a more streamlined sprint workflow and more effective scrum. Most importantly of all, we ended up with a more balanced development roadmap and, ultimately, a better product.</p>
<div class="g g-21"><div class="g-single a-170"><a class="gofollow" data-track="MTcwLDIxLDEsNjA=" href="https://www.pendo.io/pendomonium/"><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2024/06/MTP-Footer_ad.png" /></a></div></div>

Managing – not Just Maintaining – a Product Backlog

Victor Conesa

Comments

Read next