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.
Based on my experience in Agile, during product backlog refinement sessions, some projects used the MoSCoW technique, while others employed T-shirt sizing with Extra Large (XL), Large (L), Medium (M), and Small (S) to estimate PBI work efforts. If a PBI is sized as XL or L and qualifies as part of the Minimum Viable Product (MVP), it is discussed with Developers to determine whether it can be included in the current sprint. If the PBI has dependencies, it is broken down into smaller sizes (Medium or Small) and considered for subsequent sprint backlogs. Addressing unavoidable dependencies early is always beneficial.
In my experience, I have seen some projects where a PBI is shared between two developers working on different tasks. This approach fosters collaboration, reduces dependencies, and increases transparency.
The mindset of perfectionism varies among teams, but embracing imperfections allows for ongoing learning and development, ultimately leading to better outcomes. I have observed continuous improvement in both the team and the process, driven by the thoughts, ideas, and feedback shared by team members during retrospective meetings.
This was a beneficial article and my reading of it has come at an opportune time.
As I have just recently prepared my very first product backlog as a volunteer PO, as well as attempted my first backlog refinement with our development team, I can see that I did not fully understand how I should be approaching the backlog and my practical knowledge is still a bit, “rough around the edges.”
This article provides additional clarity on the ultimate purpose of the Product Backlog, as well as a practical approach to prioritization via the MoSCoW technique.
In addition, the reminder to eschew perfectionism in favor of action is perennial advice. I think for some of us, perfectionism is deep down just a fear of failure or perhaps the erroneous idea that not getting it right the first time, is not getting it right at all. Perfection is a process of iterative imperfection, with each iteration being a little less imperfect than the last.
I enjoyed reading this blog post by Loren.
Let me start off by saying that I like the topic of this article ‘How lean is your Backlog?’ It is a useful article to read to understand how Agile practitioners can apply the Lean principle of waste elimination to their Product Backlogs. The importance of prioritization, product backlog refinement, and minimizing dependencies, hand-offs, and bottlenecks in keeping a lean product backlog.
The MoSCoW technique for prioritization was particularly interesting. It helps to identify the core functionality of a product and what should be included in the Minimum Viable Product (MVP). This technique is very useful for reducing the risk of working on the wrong things or too much at once, which can lead to waste.
The article also touches on the importance of mindset in keeping a lean product backlog and emphasizes the need to ease up on perfectionism and focus on continuous improvement. This is a valuable lesson for Agile practitioners who may be accustomed to a perfectionist corporate culture. I found this article to be very informative, insightful, and relevant to anyone working in Agile.
Nice blog post by Loren that makes a lot of good points.
Point well taken that discussing every PBI in detail is a waste of effort because some (most?) of them will never make it into a sprint backlog. Of those that do, refining them far in advance is also potentially a waste. That’s because in the meantime stakeholders and developers may learn things that change their understanding of those items and therefore how they refine them. The sweet spot is some degree of just-in-time refinement to keep the pipeline sufficiently full to feed into sprints.
With regard to mindset and perfectionism, part of agility is the willingness to learn and analyze through experimentation and empiricism, when appropriate. That includes, for example, just trying something when the cost in failure is low. That can go a long way to avoid “paralysis via analysis”.