I was a Product Owner on a small Scrum Team that had been building a software product for about a year. During our first year together, we were using Scrum quite well and managing all of our artifacts, including the Product Backlog, in an analog fashion (sticky notes and whiteboards).
The Scrum Team began to explore digital tools that could help us manage our Scrum artifacts, specifically, I did as the Product Owner because it was becoming quite difficult to manage the Product Backlog. I often struggled in meetings with stakeholders to answer questions about what was on it. I was having difficulty making the Product Backlog transparent. Sticky notes would fall to the ground and mess up my order. It was time to “grow up”!
The Scrum Team all agreed that a tool to help manage our Scrum artifacts could make life a little easier. After much review and debate, we purchased a tool that we thought could help me manage the Product Backlog and make the Scrum Teams Sprint Planning a bit easier.
I was in awe of the amount of capabilities the tool had to offer. I could implement levels of decomposition, map dependencies, color code, order very quickly, create custom attributes, export to excel, and pretty much do anything else I could imagine to manage the Product Backlog as Product Owner. So I used all of the features.
The problem? I was no better off than I was before. Now, I felt, my time was spent managing a tool. I had the same struggles I had before and was no better off than when my Product Backlog Items, previously on sticky notes, were falling off a wall.
I began to unwind the mess that I had created by overusing the features I had been using in our new digital tool. I stripped out just about everything and went back to a very simple way of naming and managing my Product Backlog Items by using a naming convention.
As a vague Product Backlog Item split into many Product Backlog Items, I took the short description of the original item and kept it in the title. To illustrate this concept let’s suppose we are going to clean our house and this is our Product Backlog:
- First Floor
- Second Floor
- Basement
- Garage
- Yard
During Product Backlog refinement, the team evaluates the Product Backlog Item ‘First Floor’ and decides that it can be broken down into several smaller items that can be completed independently. We could leverage functionality in a tool but what if we simply used a naming convention such as:
- First Floor - Kitchen
- First Floor - Family Room
- First Floor - Bathroom
- First Floor - Study
I chose to delimit the Product Backlog Items with a dash but you can certainly use other delimiters. Not to dismiss the use of features of a tool because they often can help but I have long believed that simplicity creates transparency.
Going back to my context with the Scrum Team I was a part of as a Product Owner, I implemented this simple philosophy of using a naming convention and things became much easier for me. I could easily discuss and re-order the Product Backlog as I saw fit. Decomposing Product Backlog Items tool little time. It was just easier for me.
We often get caught up in the tools we use and feel like we need to get our money’s worth by using every feature. Instead of creating transparency, using every feature of a tool often degrades the transparency of the Product Backlog. Keeping things simple and using a method such as a naming convention might be all that you need. Consider what is simple, is easiest to manage, and gives you the opportunity to create the most transparency.
Learn more about me by checking out my profile: https://www.scrum.org/todd-miller