In almost all of my courses are people who use electronic tools e.g., Jira, TFS, Rally in their work. Typically such a tool is used to track bugs, and often it’s also used as a product development “backlog”. On the other hand, we have two LeSS Guides which state: “Don’t use any software tool for Sprint Backlogs; just use physical visual management, probably cards on a wall”, and for a Product Backlog tool “Use nothing more complicated than a spreadsheet and wiki”. So are those tools a curse or a blessing as so many people use them? Let me share my thoughts with you.

Since organizations often use such an electronic tool to track bugs, it might seem to be feasible to also use such a tool as “backlog”. And here comes the first problem: Which backlog do you talk about?

Observation 1: Organizations, which use a ticketing tool as a backlog, often do not understand the difference between a Product Backlog and a Sprint Backlog. This is a fatal flaw as those are two very different things. Thus, let’s look at the differences between those two.

“The Product Backlog (PB) is an emergent, ordered list of what is needed to improve the product.” (ScrumGuide2020). The PB contains Product Backlog Items (PBI), unfortunately often people call them “User Stories” even though those items are far far away from a real “User Story” and that is topic for another post. The PB is “owned” by the Product Owner (PO). Typically, the PO also uses the PB to plan upcoming work and monitors progress at the product level.

“The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint…” (ScrumGuide 2020). In other words, the Sprint Backlog contains tasks that need to be done in order to get a Product Backlog Item “done” (as in Definition of Done).

Observation 2: A team using an electronic Sprint Backlog is doing that typically for some of the following reasons:

• The usage of the tool is ordered by the management.

• The team is dispersed*.

• The team is not self-managing (and is not allowed to define it’s own work process).

• The team is not educated on the importance of visual management.

Observation 3: The typical consequences are:

• The effort for learning to use an electronic tool is higher compared to work on a physical board.

• The tool dictates the workflow. Changes in the tool are either difficult or not feasible to implement.

• Poor/No visual management leading to not seeing the whole and focusing on individual tasks instead.

• The usage of such tools support the team members to behave as a  group of individuals instead of team.

• Managers (or Scrum Master as project manager) are tempted to micro-manage the team.

So in short, using such tools as a Sprint Backlog is an evil thing  with no upsides, only disadvantages.

What about the usage as a Product Backlog?

Compared to using a spreadsheet, I experienced no benefits, only disadvantages.

Observation 4: Here are a few selected items which I observed in my case study and in my many years of coaching organizations:

• They convey a facade of improvement or agile adoption, when nothing meaningful has changed; “agile-jargon” tools have nothing to do with being agile.

• They often impose inflexible terminology and workflows to the organization, taking away process ownership and restricting improvement.

• These tools enable complexifying rather than simplifying.

• They often require significant tasks of customization, integration, and ongoing updating which drives the creation of another overhead wasteful role such as a “Jira secretary” ala a fake “Scrum Master” or “Product Owner.”

• These tools support and reinforce traditional big-batch to little-batch work breakdown structures and processes, where an old separate business group decides major items (of large size and bigger batches) that are then pushed into the development group to do in smaller sizes and batches; this is just traditional non-lean management usually with a facade new jargon, such as “epics” and “stories”.

• Lack of visibility and understanding of the big picture due to access limitations and poor visualization of the whole.

• Reduced efficiency and effectiveness of Sprint events e.g. Sprint Planning 1.

So in short, stay away from such tools for your Product Backlog.

* This is written in times of Corona and the teams are temporarily dispersed. This is still no valid reason to introduce a ticketing tool as Sprint Backlog. Instead, good experiences have been made by using Miro, Mural, and similar tools which allow collaborative working style and can mirror a physical board.

Happy Scrumming!