In my Professional Scrum Training and coaching sessions with teams, I am often asked about Product Backlog management tools. In this post, I’ll share my thoughts on tools and 3 tips for using tools effectively in Scrum.
The question is asked in a couple of ways:
First, let’s remind ourselves of the purpose of a tool. A tool is something that helps us accomplish a task or perform an operation. If we think about this in the context of Scrum, we use tools to help us deliver value and instill quality. We use tools to help us create greater transparency. And transparency helps us make effective choices based on learning and changes in our environment.
Just like how there are no best practices in Scrum, there are no best tools in Scrum. Pick any tool, and about 50% of people will think it’s okay. The other 50% will hate it with a fiery passion.
If you are doing backflips and spending a lot of time trying to “make the data look good” in your tool, then you are focusing on the wrong thing. At the very least, you are creating waste. At worst, you are actually reducing transparency and the Scrum Team’s commitment to creating value.
Here are a few examples of statements that might indicate we are focusing on the wrong things:
(Note those first two questions are problematic for multiple reasons, and I’ll be writing another article soon about that.)
Often, management is who drives this focus on the wrong things, and that drives behavior within the Scrum Teams. I make this point not to cast blame but rather to point out that we need to help management see how they are unintentionally impeding the benefits of agility and creating unnecessary waste (and probably reducing transparency).
It would be amazing to have one Product Backlog management tool that could both be useful for the Scrum Team and also automatically answer all of the questions in the organization related to progress towards goals, budgets, and more. However, I have yet to see a tool that can do that. And I highly doubt it is possible because we are dealing with complex work in complex environments. And every Scrum Team’s context is different, so their process will look different. Of course this means the tools they use to help them be effective with their process will look different.
I have 3 tips for you when it comes to choosing your tools and how you use them.
Use the simplest tools for the job. And that may mean using a different tool rather than trying to make an existing tool accomplish another purpose. When you are trying to figure out the best way to use a tool in a specific scenario (e.g. split a PBI), ask the Scrum Team what will ensure a shared understanding of the value desired and also be simple and easy to maintain.
Product delivery is not about perfect reports and data that makes us “look good.” Transparency comes from open and honest discussions and creating shared understanding. A report or data may be a piece of that, but it’s not going to get you all the way there.
Frequently ask yourself if your tools are constraining your process and/or creating more waste than the added value. And if the answer is yes, do something about it. Challenge assumptions about why a certain tool is required or why specific data in a specific format is required. Dig into the real why behind what is needed. You might find an old mindset that we just need to let go of. Or you might find a better way to accomplish the need.
Do you still want to know my preferred tool for Product Backlog management?
My answer is sticky notes and fine-tip markers. And a large visual space to collaborate. This can be easily replicated in a virtual environment. If the results of these conversations then get captured in a fancier electronic tool, that’s cool. Just keep it as simple as possible, make it easy to maintain, and keep the focus on transparency to value.
AGILE SOCKS is a registered trademark of Agile Socks LLC. Other marks used herein are the property of their respective owners. For more information see Trademark Notice in Terms & Conditions.