Digital Tools for Product Backlog

by

In a previous post, we explored the role of digital tools in managing the Sprint Backlog (https://connexxo.com/2024/02/digital-tools-for-sprint-backlog.html/).

Now, let’s take a step back and look at a crucial artifact in Scrum: the Product Backlog.

While digital tools can help teams visualise and manage the Product Backlog, they also introduce challenges that can impact collaboration and transparency. Let’s start by summarising what a Product Backlog is and how it is traditionally maintained, then we’ll connect to how digital tools influence its use.

What is a Product Backlog?

Let’s start with the definition that is given by the Scrum Guide. I’d like to go through both, the 2017 and the 2020 versions of the Guide, because I find the former much more explicit in many aspects.

Scrum Guide 2017 (*)

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done.”

As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.

(https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf, emphasis is mine)

Scrum Guide 2020 (*)

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

(https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf, emphasis is mine)

Some attributes of the Product Backlog that might be useful to note:

  • It is never complete
  • It is dynamic
  • It is a living artifact
  • It is an emergent, ordered list

What does a physical Product Backlog look like?

Before the rise of digital tools, many teams maintained their Product Backlogs using physical boards or index cards. This method has several advantages:

  • Transparency and Accessibility: A physical backlog, displayed prominently in a workspace, is always visible to the entire team and stakeholders.
  • Collaboration: Teams can easily move backlog items, discuss priorities in person, and refine work collaboratively. A digital tool, in my experience, always adds some friction to these activities. People seem to be afraid of dragging and dropping something on a complex digital tool but they are not when doing the same with a physical card.
  • Tactile engagement: Writing items by hand and physically interacting with them can enhance understanding and retention.
  • Large collaborative workspace: Even a large digital display is often too small to show the entire Product Backlog in a readable way. Scrolling through a digital backlog means losing sight of the bigger picture, whereas a physical backlog allows the team to see everything at once and to interact with it more naturally.

Remote teams and digital tools for Product Backlog

If you have fully remote or even hybrid teams (my opinion on this topic is in the previous post), using a physical Product Backlog might result in an impossible job.

When choosing a digital tool you have plenty of choices: from the simplest solution (something that mimics a wall or a shared spreadsheet) to the most complex and unfortunately feature-bloated ones (then marketed as “structured” or “configurable”).

Side Effects

As in the case of Sprint Backlogs, there are also some effects that you might observe in teams using these tools for maintaining their Product Backlogs.

The more the tool is on the right, the more of the following you might notice:

  • The “my document” effect -> how the person who has control of the tool in a meeting determines its pace.
    • Speed and effectiveness in handling the tool
    • Speed and effectiveness in retrieving the information
    • The person using the tool effectively steers the discussion, so their understanding of the problem is crucial
    • The way the “tool controller” writes the information will have an impact on how the team works: level of detail in writing the info or how the data is connected to other information.

    While these effects are also present when using paper, the fact that one person is leading the “visible” discussion prevents others from taking a more active role in moderating the meeting and modelling the information appropriately. After a while, the whole team becomes more lethargic during the meetings, resigned to the fact they don’t control their information.

  • The “database effect” effect -> digital tools make it easy to collect information, and, therefore, often result in a huge collection of data, causing overly long backlogs. This doesn’t usually happen with paper Product Backlogs because physical space is a constraint.
  • The “complexity intensifier” effect -> as it’s possible to collect and add complex information easily, the organisation often creates not just long, but also very complex backlogs, that are difficult to maintain, understand and develop. This might also create what is called explicit knowledge information overload (see for example https://slick.plus/blog/explicit-vs-tacit-knowledge-understanding-the-differences-and-their-impact-on-organizations/). Again, this is usually not the case for paper Product Backlogs.
  • The “information degrades” effect -> information gets old over time, for several reasons:
    1. As we develop a product, we get more insights and understanding of what we have to do. What we have documented in the past becomes outdated over time, both in the form and in the substance.
    2. The “market” view of what we do changes over time: customers and users develop their view of what our product should be about, so what we have collected in whatever documentation we have is bound to become old anyway.
    3. The product we build reflects both 1. and 2. and this means that both, documentation and architecture related to the system are bound to become old as well. As such, the more information we collect in a backlog, the more information degradation we have to deal with over time. Keeping the backlog minimalistic and essential is a necessity to be able to maintain it in an adaptive/agile way.

    With a digital tool, the tendency to keep outdated information is higher than when using paper cards. In the latter case, during Backlog Refinement, a new, updated and more precise card may be written and the outdated one physically discarded.

  • The “it’s for you, for later” effect -> as it’s possible to collect information very easily, many people in the organisation just put things in the backlog that teams don’t have the time and the bandwidth to understand and refine instantly. Apparently not an issue: it can be done later, but “later” means
    1. Working with information that has degraded over time
    2. Analysing problems with a long time lag to their occurrence, i.e. much more work to “recap” what happened since then and adapt it to today’s scenario
    3. In the end, the backlog becomes more of a “specification” and less of a live document we all use to explore and understand where to go next. This is actually an impediment to an experimental mindset.

    Together with other effects, it creates backlogs that are very complex to use.

  • The “regular review” effect -> a long and complex backlog requires more effort to review periodically to determine what content is still adequate and what requires updates.
  • The “history” effect -> with electronic tools, it is possible to keep the history of the work. While in some cases there are regulatory needs involved, for the vast majority of the cases there are not, but the organisation still collects the history of what is being worked on. Also, even when there are regulatory needs, it’s very likely that history shouldn’t be always visible. This results in a large collection of information that is useless in practice and, even worse… (see next)
  • The “Italian law” effect -> Italian laws are written as successive changes to previous laws, i.e. to understand what is the actual text you need to take the original text and successively apply each modification. I’ve seen backlogs where there was an initial description of an item, and then there were updates described usually in the “notes” section in the form of “date: decision”, but all the previous text is left unchanged. This means that every time the team discusses an item, they have to re-apply the whole history to re-understand what was the topic. I’ve seen items where the title had, over time, absolutely nothing to do with the current version of the topic.
  • The “watch there, not me” effect -> the team looks towards the projected image, not to each other, degrading the quality of the collaboration. The projected image becomes the focus and we miss all the non-verbal parts of the communication and the interaction.
  • The “serialisation of discussion” effect -> with a paper backlog it is often the case that, when discussing a certain topic, team members change in parallel several cards related to a certain work. Maybe the tasks of a PBI, maybe some changes need to be reflected in several PBIs. When using an electronic tool, it is obviously possible to do something similar by having several team members using the tool in parallel, but for some reason, this does not actually happen.
  • The “nice words” effect -> where the team focuses on the wording of things more than the content. Words are important, and how we name things is a reflection of how we deal with them, but a backlog in electronic format “inspires” the teams to look more at the formal aspects of how a backlog item is written and less at system modelling. This is an effect that can be seen even with paper backlogs when the team is using the “as a / I want / so that” template, but it is worse when an electronic backlog is used.

Possible countermeasures

Here are some strategies that might be adopted to reduce or remove the effects described above:

  • If you decide to use digital tools for one reason or another, focus on the content and transparency of the Product Backlog and not on the tool used. Especially when starting with a new Product Backlog, use the simplest possible digital tool. A shared digital board (like Miro or Mural) might be more than enough.
  • Choose a tool that supports active collaboration during Product Backlog Refinements, Sprint Planning and other meetings. The possibility for multiple people to edit the backlog at the same time while seeing what the others are doing is crucial.
  • Avoid adding “stuff” to the Product Backlog just because it is cheap to do so. Having a lot of Product Backlog Items on a digital board (like Miro or Mural) might create some friction, but that should be considered a feature, not a bug. Even then, if the size of the backlog is too large for these kind of tools, a shared spreadsheet might be more than enough to solve the problem.
  • Balance Tacit and Explicit Knowledge. The core challenge in Knowledge Management lies in striking a meaningful balance between Tacit Knowledge (the expertise and insights in our minds) and Explicit Knowledge (formal documentation). Many organisations instinctively push for making knowledge more explicit, often underestimating the cost and complexity of maintaining extensive documentation. Agility, while not always stating it outright, takes a different approach – embracing Tacit Knowledge as a valuable asset. When effectively shared within a team, it enables smooth collaboration without the burden of excessive documentation. The key prerequisite, therefore, is a team that works closely together and actively exchanges knowledge. In this sense, a strong team functions as a social structure that facilitates Tacit Knowledge sharing, reducing the typical challenge of its intangibility and difficulty in being transferred.
  • Avoid complex categorisation and hierarchies in the backlog. A plain list of Product Backlog Items might be enough. If some categorisation by a higher level of abstraction is needed, using tags is usually a good solution (i.e. tagging per “theme”)
  • Keep documentation and Product Backlog separated. An example might be using a shared spreadsheet for the Product Backlog with links to a Wiki for documentation.
  • Avoid using templates to write Product Backlog Item titles. Here, I would like to quote Ron Jeffries:
    As an author of the Agile Manifesto / I want that stupid story format to go away / So that people can get to the essence of user stories.I don’t know if it’s still there, but once upon a time this appeared on https://twitter.com/ronjeffries/status/718045486372954112
  • Coach the organisation in avoiding mandatory tools and in understanding how self-managing teams work. This is the only way for Teams to be able to experiment and adapt the tools to what they need instead of the other way around.

Final thoughts

As we’ve seen, working with a digital Product Backlog has some shortcomings, but for remote or hybrid teams it’s sometimes the only option. While digital tools can introduce friction in collaboration and transparency, their impact depends largely on how you choose the tool and how you use it.

The key takeaway is that teams should focus on adaptability – by choosing tools that support collaboration rather than constrain it. Keeping the Product Backlog simple, avoiding unnecessary complexity, and ensuring it remains a living artifact rather than a static repository of outdated information are crucial for maintaining agility.

Looking ahead, digital backlog tools will likely continue to evolve and maybe improve real-time collaboration. These advancements could help mitigate some of the common challenges we’ve discussed. However, no tool can replace the need for strong team collaboration, continuous refinement, and shared ownership of the backlog.

Ultimately, the best approach is to experiment – teams should try different ways of managing their backlogs, reflect on what works, and refine their practices accordingly.

(*) The Scrum Guide is © 2020 Ken Schwaber and Jeff Sutherland. Content from The Scrum Guide is used by permission of Ken Schwaber and Jeff Sutherland under the terms of the Creative Commons – Attribution – Share-Alike License v. 4.0. which is accessible at https://creativecommons.org/licenses/by- sa/4.0/legalcode and also described in summary form at https://creativecommons.org/licenses/by-sa/4.0/.