|Door:||Willem Vermaak, 18-04-2017|
|Onderwerp:||Product Backlog Management|
During Scrum2017 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 whitepaper! It will become freely available as soon as possible!
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 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 the Product Backlog.
Agile Manifesto Value 1:
Agile Manifesto Principle 10:
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 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).
For more information on the Scrum pillars, see the Scrum Guide
Tip 4: Not everything has to be a "User Story"
For the Dutchies: read THIS - 'nuff said
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.
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:
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 Scrum2017 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?
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:
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
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.
(INVEST - Independent, Negotiable, Valuable, Estimated/estimable, Small/Sized appropriately, Testable)
(DEEP - Detailed appropriately, Estimated, Emergent, Prioritized)
Tip 11: Use a Story Map for more insights
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 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!
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!
Would you like to add some more tips? Or would you like to share your thoughts on the tips I provided? Then please speak up! I’m always looking for tips and feedback to learn from! I hope you enjoyed this blog!
Thanks to Robbin for the support, proofreading and wording, and thanks to all the participants in the workshop for your insights and making this a better blog!