One of the core principles of Lean is to eliminate waste. For those of us working in Agile, it’s important to consider what this means for our Product Backlogs. What are the waste reduction concepts that are currently in practice? And probably most important, what waste reduction ideas are suitable for my backlogs?
While I’m only scratching the surface of possible waste reduction ideas, here are my reflections on common efforts we do to keep our SVPM backlogs lean.
Prioritization
Prioritization is the name of the game for keeping a lean product backlog. I doubt I’m telling you anything new here. Product Backlog Items (PBIs) get prioritized by the value they bring to users, customers, and/or other stakeholders. My preferred method for doing this is the MoSCoW technique. MoSCoW stands for:
- Must have
- Should have
- Could have
- Won’t have for now
The Must Haves essentially make up the Minimum Viable Product (MVP). If you leave out a Must Have, the product won’t work.
The Should Haves might not address core functionality, but they still add a lot of value for the users, customers, or stakeholders. Once we identify our Must Haves and Should Haves, we know where to focus our efforts, reducing the risk of working on the wrong thing or too much at once.
The Could Haves are a judgment call. While they still provide value, it’s less valuable than the Should Haves. The Product Owner ultimately decides the line between the two after gathering opinions from appropriate stakeholders.
Won’t Haves are out of scope and not included in the Product Backlog, at least not for now. Since Agile is about adapting to change, the perceived value of these PBIs could change and they might warrant reprioritization.
Product Backlog Refinement
Product Backlog Refinement is the process of the Product Owner meeting with the Development Team and possibly users and business stakeholders to make sure that the top PBIs are well understood and ready to become part of a Sprint Backlog. Since we’re mostly concerned with the PBIs that could end up in an upcoming Sprint Backlog, there is no need to discuss every PBI on the list. We’re being Lean here by not spending our valuable time and effort on PBIs that may never move on to a Sprint.
By encouraging the Developers to collaboratively clarify the top PBIs with the Product Owner and other stakeholders, we reduce potential defects and rework that could arise during the Sprint. Problems and issues are uncovered and dealt with early before they become bigger problems later. The biggest benefit from this collaboration is the increased communication amongst the Developers, who will be doing the actual work, and the Product Owner, users, and other business stakeholders. Everyone is on the same page regarding the PBI objectives.
Dependencies, Hand-offs, and Bottle Necks
As much as possible, we want to keep PBIs independent of each other. That means we don’t have to finish one PBI before we can start another. Anytime there is a dependency, there is a hand-off. Hand-offs cost time. One person may need to spend time explaining the PBI they just finished and the other person may need time to come up to speed. However, we live and work in the real world, and sometimes we need to accept certain hand-offs during a Sprint. For example, when I finish writing this article, someone else will need to edit it. While it is unfortunate that we have this hand-off during the Sprint, we decided it was more important to publish new content each Sprint rather than write it one Sprint and edit it the next. But by drawing attention to the hand-off, we can streamline it as much as possible. As the writer, I see the editor as a collaboration partner and I try to provide her with something to edit as early in the Sprint as possible. This tactic might not be appropriate for every development team, but it seems to be working for our situation.
Mindset
One lesson I recently learned and am attempting to put into practice is to ease up on perfectionism. I, like I’m sure many of you, am a product of a perfectionist corporate culture. I’ve had it drilled into me “don’t make mistakes” and “get it right the first time”. That mindset may be appropriate in certain situations, but in my Agile experience, more focus is on working with what’s in front of you as best you can, moving on and doing the work, then taking what you’ve learned to apply to the next thing. At SVPM, we have a number of reoccurring PBIs that show up Sprint after Sprint. These PBIs are evolving, they are getting more streamlined, and clearer, with fewer or simpler hand-offs. As the team matures, and we have more open discussions about these PBIs, we keep making them better, one small improvement at a time.
Image adapted from photo by Christina Morillo.
