During Scrum 2017 I hosted a workshop about Product Backlog Management. It seems people are eager to learn about it, since it was fully booked! We had a great session in where I shared a lot of information (perhaps a bit too much), and also received a lot of great feedback and input from the audience. At the beginning of the workshop, I shared my personal vision: “Create, develop, train and coach the best possible Product Owners“.
So in order to embody my vision (and by following on the promise to the participants I would write down the tips I gave) I hereby would like to share my thoughts on Product Backlog Management with all Product Owners (or Scrum Masters, Product Managers, Project Managers, enthusiasts, really… just anybody) out there!
Despite the fact that I usually tend to stay away from ‘The 5 best ways to…’, or ‘The ultimate 7 …’, I will make a small exception and present: ‘The 12 Product Backlog Management tips to ensure smooth and powerful Product Backlog Management’
Before I start: When I was initially writing this blog I had so many examples and tools for each of the 12 tips that it grew to a very extensive blog, so in order to keep the readability up I’ve decided to split it. This blog will contain a short subtract of all the tips and I’m currently writing a whitepaper on Product Backlog Management in which I will further elaborate on all the tips. So if you like what you’ve read here, stay tuned for the upcoming whitepaper! For now: here we go!
Tip 1: It all starts with a (clear) Product Vision!
If you don’t know where you want to go, how could you possibly decide what direction to take? Before you can do anything with regards to Product Backlog Management, Product Backlog Items, etc, it is vital that you first get clarity on ‘the why’ of your Product. Good Product Owners will constantly check their (next) Items against their Product Vision, in order to ensure they are going in the right direction.
Tip 2: Agile manifesto Value 1 and Principle 10
Of course, all Agile Manifesto values and principles are important. However, I believe value 1 and principle 10 are the most important for a Product Owner to be the champion of Product Backlog Management.
Agile Manifesto Value 1:
Individuals and Interactions over Processes and Tools
Agile Manifesto Principle 10:
Simplicity, the art of maximizing the work not done, is essential
Value 1 is important, because it is not so much about how shiny your Jira looks, or how neat your Excel is, but it is all about having the right conversations with the right people. A Product Owner that is not available for stakeholders, and ‘requests stakeholders to Email the Product Owner when they Have added an Item into Jira’, is a BAD Product Owner. Great Product Ownership is all about passion and communication! And of course I don’t mean communication via tools, but face-to-face!
Principle 10 is important, because living and breathing this principle will allow the Product Owner to keep the Backlog manageable (also see Tip 6). It is important for Product Owners to make choices on what to spend time on, and try to build only the most valuable Items (or reduce as much risk as possible).
Tip 3: The Scrum Pillars
The Scrum Pillars are essential for good Product Backlog Management! The Pillars are: Transparency, Inspect and Adapt. A good Product Owner makes sure it’s Product Backlog is as transparent as possible. Make sure people have access to it, can talk about it and exchange ideas. Making the Product Backlog transparent will allow for inspection. This may be during Sprint Review, but also during other interactions with stakeholders.
By providing opportunities for stakeholders to inspect, you alse create opportunities to adapt. Make sure you keep moving in the right direction by constantly steering towards your vision.
Transparency, inspection and adaption will allow your Product Backlog to be a living artefact, and this allows you to adapt to changes in the market, requests from stakeholders and it supports you in having the right conversations with your development team(s).
Tip 4: Not everything has to be a ‘User Story’
For the non-Dutchies: Don’t try to force everything into the User Story format. There is plenty of work to be done to the Product that will not fit within that template. It could be some technical research to be done by the team (often called a Spike), or perhaps a defect in the system (often called Defect or Bug). It’s not mandatory (in contrary!) to write down every Item on your Product Backlog as a User Story. Otherway put: Not every dog is a Dobermann, but every Dobermann is a dog. So: not every Product Backlog Item is a User Story, but every User Story is a Product Backlog Item. Stop thinking in terms of only User Stories, and start thinking in terms of Product Backlog Items.
Tip 5: DOVE – The basic information your PBI should contain
Every Product Backlog Item should at least contain:
So, a description that says something about what you want, an order on the Product Backlog, a note somehow on what the potential value is that could be delivered (remember here that for instance reducing risk on something is also delivering value (knowledge value) and an estimate (preferably relative estimation (e.g. Story Points).
Ensure that DOVE is acted upon for all the work to be done by the Development Team (even if it’s just a small thing in everyone’s opinion) and that the Items on the Product Backlog are clear by applying DOVE.
Tip 6: Keep your Backlog manageable!
There is a risk that your Product Backlog will become a huge bucket with tons of Items, just for the sake of “otherwise I’ll forget it!”. Don’t let that happen!
Make sure your Product Backlog contains no more than 6 to 9 months of work (not set in stone, this could vary depending on your situation), have major Items on the Roadmap and for the rest: it will come up when it’s needed.
Feedback I received during the Scrum 2017 session from 1 participant was: “I get this point. However, we have this large Backlog. For us, the items are not really in the way. The stuff is just there, not harming anyone.”
Okay, I can imagine it feels that way; however, think back about tip 1, 2 and 3. Combine these and you’ll see that a rather small Product Backlog always has the preference. Think about it: making your Backlog transparent; how great would it be if you could print out your backlog and stick it on a big wall (making it physical is a great way to enable to conversation – hidden tip!). Good luck doing that with 300+ Items… Next to that you want to maximize the work not done (remember principle 10 from the Agile Manifesto?) and be responsive to your Product vision. How will a major list of Items support that?
So, as a Product Owner, you’ll need to learn to master the art of saying “No!” (and there are many, many, many, ways of saying no! We believe there are at least 50 shades of no!)
Tip 7: Order on Value, Dependencies and Risk
As a Product Owner it really is up to you to decide what Items are most valuable and need to be on top of your Product Backlog. When making choices as a Product Owner on how to order Items, I would suggest 3 considerations:
– What is the highest value Item (which is also small enough to be build in 1 sprint)?
– Where is the biggest risk (reducing risk reduces potential complexity and allows for the creation of more value)?
– Where are (major) dependencies?
Based on these 3 considerations you can order the Items so that you can truly maximize the value of your Product; whether it is by actually delivering value, or by eliminating risk or disconnecting dependencies.
Tip 8: The Backlog Quadrant (you should do more then only build features)
The Backlog quadrant is not a model I’ve created myself. It’s a model I’ve learned at Prowareness and I’ve adjusted it a bit to fit with my personal story. Look at this picture:
In the whitepaper I will elaborate on this quadrant more, but the main take-away for now: You, as a Product Owner, should think about more than only building Product Features. There are more ways to “maximize the value of the Product”.
Working with software always means that you will need to make trade-offs. You need to make hard choices! Even if you have the best development team in the world, bugs will appear. Even the best development team in the world, will have some form of Technical Debt (unsure what that is? Read this post from Martin Fowler). And next to that, you need to invest in the infrastructure and architecture of the platform. So, as a Product Owner, you will need to find the best possible balance for your Product.
Tip 9: Split too large Items
In my experience, a lot of teams struggle with too big Product Backlog Items. They are unable to split them, making it harder to finish the Item within the Sprint. An awesome practice I have started using is one I’ve recently learned from Mike Cohn, so many thanks for that Mike!
The simple analogy to split Items I’ve learned is: SPIDR. Split Items using the SPIDR approach:
Spikes – do (a little bit of) technical research, in order to better understand the Item
Paths – Split the Item based on the path through the application; so if you can log in with Facebook, LinkedIn, Google+ and Twitter, perhaps first build “Login with Facebook”. Then later, add the rest.
Interfaces – Consider first delivering a ‘plain’ version of the Product. Sure, the basics should look okay, but the icing on the cake can be done in the next iteration
Data – Consider only using a subset of the data. This can be on data you have on the subject, but also on data types. Two examples:
1. For a second hand car website, for your first iteration you can only search on make, model and color. Then, in the second iteration we will add ‘search on number of doors’, etc etc
2. For the first iteration we will only support ‘export to Excel’. For the next iteration, we will add ‘export to csv’, etc etc
Rules – Consider relaxing business or technical rules for your first iteration. E.g. ‘The system should load within 5 milliseconds’. Perhaps you first build it in such a way it loads in 7, and then optimise in later sprints
When splitting Items this way, please remember: the goal is not to split Items for the sake of splitting Items. A few reasons you would want to split Items could be that the Item you have is too big for the sprint (which means the teams does not feel comfortable it could finish is within 1 Sprint), the team feels it would be better to split it (perhaps since it is easier for them to pick something up) or that you as Product Owner see a chance to deliver (business) value earlier/better/faster when splitting an Item and splitting could result in receiving feedback quicker.
Next to that, the goal is not to split in all the SPIDR ways, but you can use SPIDR to find the best way to split an Item (so, either split it on Interface level, or follow the Path).
Tip 10: Make sure your Items are ‘Ready’
Make your life as Product Owner easier, and set yourself this goal: Before we start Sprint Planning, the Development Team already knows which Items we want to pick up for the next Sprint.
Having this goal, ensure you do whatever is needed to achieve that goal. Doing refinement sessions on a regular basis is a powerful way for getting Items “ready for Sprint”. Make sure to regularly meet with the team (as a guideline: refinements regularly consume about 10% of the capacity of the Development Team) to discuss Items on your Backlog.
I know there are quite some teams who have adopted a ‘Definition of Ready’. It is not really something I work with as there is a risk it creates an un-needed level of strictness preventing from inspection and adaption of Backlog Items during the Sprint itself. You could however use acronyms like INVEST and DEEP to ensure you have the right information in your Backlog Item, but the most important thing is always to have the conversation with the team.
(DEEP – Detailed appropriately, Estimated, Emergent, Prioritized)
Tip 11: Use a Story Map for more insights in your Product Backlog Management
Although the Product Backlog is an ordered list of work to be done to the Product, you could argue it is quite ‘2 Dimensional’. It can be hard sometimes to get a good overview of how the Product will eventually work.
Also during the workshop, this is feedback I received from 1 participant: “I understand the concept of a Product Backlog, but isn’t it still needed to have something like a bigger picture or flowcharts to keep an overview of everything that you are building?”
And I can imagine that necessity! One very cool way for creating such a picture is by using a practice called a ‘Story Map’. A Story Map allows you to put Product Backlog Items both in a sequential order, as well as visualizing alternatives. A Story Map might look something like this:
So imagine building a game; you would start top left with ‘loading the game’, then you might ‘start a new game’, or ‘view previous highscore’. More on this in the coming whitepaper!
Tip 12: Determine the value together with stakeholders and your development team
In earlier tips, I’ve already stated something about ‘value’. I often facilitate Product Owner trainings, and I get a lot of questions about the topic ‘Business Value’, like: “How do you determine value?”, “What is value?”, “Is value only about money?” and many, many more.
The take away for this tip is that you should not determine what business value if your Product all by yourself, but instead use the insights and knowledge of your stakeholders and development team (yes, your Development Team can also help you to discover the business value!). In order to determine value together with your stakeholders and team, you might want to facilitate a value-estimation session, which is similar to planning poker, in which you estimate the relative value of Items (“Item A is definitely twice as valuable as Item B, so let’s build A first!”). Of course this is just ‘a’ practice. In the whitepaper we will share more!
Closing notes: how to improve your Product Backlog Management?
All right, there you have it! Twelve tips on improving your Product Backlog Management skills! Good luck by bringing this into practice and improving your Product Backlog! In the meantime I’ll be busy behind the scenes elaborating on some tips in the whitepaper that will follow soon and by working on concrete examples. Once it is available I’ll post something about it! Stay tuned!