Digital Tools for Sprint Backlog

A while ago, I ran into a couple of posts written by Bas Vodde on the LeSS blog in January 2020:

Digital tools considered harmful – Sprint Backlog
(https://less.works/blog/2020/01/10/digital-tools-considered-harmful-sprint-backlog.html)

Digital tools considered harmful – Jira
(https://less.works/blog/2020/01/16/digital-tools-considered-harmful-jira.html)

These posts were written just as COVID was beginning to explode worldwide, so while what is written in there is still relevant, it’s time to get back to this topic and expand it with what we were forced to learn since then.

I’ll split this into two posts: this one focused on the usage of digital tools for Sprint Backlog and a future one focused on digital tools for Product Backlog.

Before digging into digital tools, I’d like to start from the beginning and have a look at what is a Sprint Backlog and what a physical one looks like.

What is a Sprint 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 Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.

The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal. As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

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

Scrum Guide 2020 (*)

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

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 in order to achieve the Sprint Goal.

Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

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

The key points to me are:

• It’s created and used by developers to plan their work during the sprint. No one else has a say in it
  • Sprint Backlog is a plan by and for the Developers
  • Only the Development Team can change its Sprint Backlog during a Sprint
  • The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team

• It might be used also to track content that does not come from the Product Backlog
  • To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting

• It’s a living artefact and can change notably during the Sprint
  • The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint

What does a physical Sprint Backlog look like?

When it comes to physical Sprint Backlogs, you might be surprised to see how different teams might create very different artefacts.

It’s not about being right or wrong. It’s about the team owning their process and creating a Spring Backlog that supports their work instead of being something that they must do.

Remote teams and digital tools for Sprint Backlog

I still think that being co-located for a team is a big advantage and there is enough evidence supporting this. See for example:

• https://public.websites.umich.edu/~igri/publications/Teasley%20et%20al_00.pdf
• https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0014279
• https://sacj.cs.uct.ac.za/index.php/sacj/article/view/54

Sitting around the same table and having face-to-face conversations enables a much higher level of collaboration. Being able to hear some colleagues talking about a topic makes it much easier to contribute to that conversation. Quickly sketching a possible architecture for a piece of software on a whiteboard without having the constraints of using a computer makes the process faster.

While I still believe co-location is extremely important for a team, many organisations are, unfortunately, going in a different direction.

Please, do not fall in a false dichotomy: it’s not about working 100% of the time co-located versus 100% of time remotely. The right question in my opinion is what percentage of their time a team should spend working face-to-face to see the positive effects mentioned above? The answer may vary from team to team and during a team life.

Anyway, if you have full remote or even hybrid teams, using a physical Sprint Backlog might result in at least a painful (if nobody is in the office on a certain day) if not almost impossible job (if everybody works always from home).

Some teams, working in a hybrid setting, try to have both a physical and a digital version of the Sprint Backlog. I tried this many years ago and I’ve found that keeping both versions in sync was quite painful. An alternative might be using only a digital tool and having it projected on a wall or a big screen when working physically together.

Tools and side effects

When choosing a digital tool you have plenty of choices: from the simplest solution (something that mimics a wall) to the most complex and feature-bloated ones (someone might say “structured” or “configurable”).

There are some effects that you might observe in teams using these tools. The more the tool is on the right, the more of the following you might notice:

• The “sorry, not updated yet” effect -> when discussing a topic, the team realises that an element in the digital Sprint Backlog is not updated and starts updating it on the spot: this takes much longer than making a note on a post-it and disrupts the flow of the meeting. The focus shifts from understanding progress to updating the tool (usually for reporting).

• The “my job, your job” effect -> most of the structured tools invite or force assigning the work to a single person. This results in a loss of cooperation in the team and shifts accountability from the team to individuals.

• The “tool is the process” effect -> the vast majority of electronic tools are not “supporting a process” but “defining a process”, i.e. they implement a certain way of thinking about the problem to solve and in so doing force the users to adopt such a model, be it right or wrong for them. “Agile processes” are meant to be adapted to suit the necessity of the people who use them, but digital tools are often impediments to this adaptiveness. Even worse, “becoming agile” using a tool means the team will never learn from experience, but rather “use a process” invented by somebody else, regardless of whether it is an effective process or not.

• The “tool inescapability” effect -> especially in large companies, tools are mandated “from above”, and they usually come pre-configured by somebody else, i.e. with their view of what agile processes should look like. In my experience, this view is at minimum very primitive and often dysfunctional and full of misunderstandings. Many teams take the tool “as is”. Very often any configuration is locked by the organisation, usually with the pretence of standardising the “reporting”, but the result is a team locked in a process they don’t understand and don’t agree on; it’s dysfunctional for them and they are not allowed to change.

• The “PO/SM/Management progress tracking” effect -> someone other than the team does the progress tracking during the Sprint. It might be the Product Owner, the Scrum Master or a manager, but it all comes down to misusing Scrum for micro-management purposes. Tracking progress during the Sprint is something that belongs to the team and no one else (more on this here: https://connexxo.com/2023/11/laws-sausages-and-sprints.html/)

• The “measure everything” effect -> metrics needed by Product Owners and managers should be Product metrics and therefore should be derived from the Product Backlog. Metrics derived from the Sprint Backlog might be useful for the team but usually become monsters as soon as they’re used by someone else.

• The “avoid the pain” effect -> very often, creating a task with one of these tools is much more complicated than writing a Post-it (rules, mandatory fields, impossibility of deleting items created by mistake…). As a common result, the team will avoid using the tool as much as possible and skip splitting Product Backlog Items into fine-grained tasks. However, large tasks lead to less shared work, which leads to high work-in-progress and half-baked items at the end of the Sprint.

• The “communication through the tool” effect -> since the organisation understands only what goes through the tool, the team starts to communicate through the tool, too. People “write comments on issues” instead of talking to each other or “assign tickets to each other” instead of asking for help. Again, this results in a loss of cooperation in the team and shifts accountability from the team to individuals.

Final thoughts

Many people and many teams have worked only with highly structured tools and have not been exposed to more collaborative alternatives.

A Scrum Master/Agile Coach (yes, they are the same thing, but this is a topic for another post…) should:

• Coach the team in owning their process. It should be tool-agnostic, so it’s better to first focus on the process before focussing on the tool.
• Coach the team in choosing a tool that fosters their collaboration and to adapt it while they evolve and improve.
• Coach the organisation in avoiding mandatory tools and understanding how self-managing teams work.

Usually, a simple tool has fewer constraints than a complex one and it is more adaptable to the process created by the team… and it doesn’t steer the team into defining a process. Therefore, a good question might be “What is the simplest thing that could possibly work?”, which might sound familiar to XP Practitioners.

---

(*) 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/.