Or Three Ways Product Owners can Stay on top of Scrum
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.
The Challenges of Backlog Grooming
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.
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 – 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: prioritizing major product changes against small tweaks becomes impossible with everything piled together in the backlog. 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.
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
Mini-backlogs, More Organization
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.
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.
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. Scrum poker works for us: the team estimates each task in the backlog according to a points system – 1 for easy up to 16 for epics – using personalized Scrum cards, a relaxed yet focused approach that encourages honest discussion and more efficient story estimation.
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.
Split Backlogs, Split Roadmaps
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.
For some agile teams, splitting user stories into two separate roadmaps might mean dividing out the product owner’s responsibilities between two new roles, say product backlog manager and product owner, as Andrew Petro argues. While this isn’t mandatory, it is another solution for when the product backlog starts to sprawl.
Velocity Tracking
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.
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.
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.
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.
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.
Pro-active Backlog Management: The Benefits
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.
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.
Comments 1