Digital tools considered harmful - Sprint Backlog

Digital tools considered harmful: Sprint Backlog

It is unfortunately common to use a digital Sprint Backlog. I explicitly say ‘unfortunately’ because of the negative impact a digital Sprint Backlog tends to have on team dynamics and collaboration. Using a digital tool for a Product Backlog might also be common but is less harmful. Digital Sprint Backlogs should be avoided!

I’ve observed four causes of digital Sprint Backlog,

  1. The team is not co-located.
  2. Management mandates a tool for Sprint Backlog.
  3. The team uses a computer during Sprint Planning.
  4. The Scrum Master adds tasks to the Sprint Backlog.

Each cause is a reflection of a team or an organizational dysfunction.

1) The team is not co-located

Dispersed teams are common as many companies pretend co-location doesn’t matter and allow organizational stupidity to disperse the majority of their teams. Check out my article related to this, called “co-location still matters!

Dispersed teams frequently end up quickly deciding to use a digital Sprint Backlog. Yet, I’ve known quite some teams that manage fine with post-it Sprint Backlogs, white boards, video and photos.

2) Management mandates a tool for Sprint Backlog

Although I have often inquired about the benefits of ‘harmonizing’ the Sprint Backlog tool, the reasons to do so are still unclear to me. The most common response is a desire for better in-Sprint progress tracking. This is a clear sign Scrum is being misused for micro-management purposes as in-Sprint progress tracking is the responsibility of the team. Another frequent response is to derive metrics from the Sprint Backlog, but the metrics for tracking team progress and release management are derived from the Product Backlog and not from Sprint Backlog.

The Sprint Backlog is for the team; not for the Scrum Master or for the Product Owner, and definitively not for management. It helps the team to take a shared responsibility and to manage their work toward creating a releasable product Increment. What tool (or not) to use is the decision of the self-managing team. Management that mandates a tool doesn’t seem to understand Scrum and how it is founded on self-managing teams. That is the real problem to solve.

3) The team uses a computer during Sprint Planning

Computers cause boring meetings. They centralize discussions with the typing person becoming a bottleneck. Computer-centric meetings are life-sucking events and waste people’s time as they stare at the ceiling while waiting for the typist to finish.

Computer-less meetings can be much more productive and fun. Meetings automatically decentralize when the focus is on conversation and using cards or post-it notes to invoke collaboration. Everyone writes in parallel. Sub-groups emerge and later merge again. And the cards on the table provide an overview of what was done.

Sprint Planning is shared software design and ought to be fun!

4) The Scrum Master adds tasks to the Sprint Backlog

Scrum Masters who touch the Sprint Backlog will own it and they become fake-Scrum Project Managers.

Example: Non-digital Sprint Backlog

Following is a non-digital Sprint Backlog from a team I worked with.

Example Sprint Backlog

This Sprint Backlog is the software design of the system, with the black boxes representing the current system and the red ones the envisioned design for this Sprint. The post-it notes are the tasks needed to do. This is the ‘to-do’ column of a task-board Sprint Backlog.

I’m not suggesting that your teams should work this way. This is how this team worked, they owned it. That is the most important reason for never using digital tools for Sprint Backlog. When using a digital tool, the tool determines the way the team is working. Without digital tool, the team can own and improve their own way of working.

comments powered by Disqus