At the time of this writing, Jira is probably the most widely used digital tool in Scrum and LeSS adoptions. Unfortunately, using Jira commonly leads to some predictable dysfunctions. Some of these are:
Many companies start “enterprise-wide” Scrum adoption with mandating Jira. People learn Scrum through Jira, or so they think. However, Jira was never a Scrum tool. It is an issue tracking tool with many ideas integrated into it, such as Scrum and many… not-Scrum. Teams end up adopting ideas that they think, or were told, are included in Scrum.
The overall result is anti-Scrum. How? Scrum has a minimum of prescriptions as it implements empirical process control. Team practices are not prescribed or fixed but are adopted and adapted as context changes. Scrum implies team-owned processes rather than tool-owned processes.
Jira integrates the Product and Sprint backlog. This might seem like a good idea but in practice, it is not. It leads to confusion about their purpose.
The Product Backlog contains items that represent product features or improvement work. The Product Owner uses the Product Backlog for tracking product progress, deciding features to create next, and for making scope/time/cost trade-offs.
The Sprint Backlog is a plan from the Team on how they are going to attempt to achieve the goal of the Sprint. It is valid for one Sprint – it is created at the start of the Sprint, never earlier, and ceases to exist at the end of the Sprint. The Team keeps it up-to-date all the time. It enables them to take a shared responsibility and manage all the in-Sprint work.
Integrating the Sprint Backlog and the Product Backlog easily leads to the Product Owner and management starting to track in-Sprint progress. By doing so, they take over the responsibility of the Team to manage their own progress during the Sprint. The temptation to interrupt the Team during their Sprint is often irresistible. And this will change Scrum from a framework for supporting self-managing teams to a micro-management framework.
Good teams avoid having half-done items at the end of the Sprint. They do so by truly taking a shared responsibility and by working one (or a few) items at the time. They achieve this through fine-grained task splitting so that each team member can pick up tasks related to the same item at the same time.
Creating tasks in Jira is slow. This might be because Jira itself is slow – most of my experiences with Jira were self-hosted installations (due to cloud restrictions) and they were all slow. Or it might be because tasks are created in Sprint Planning with one person typing. Whatever the slowness reason, all teams I’ve observed minimized their Jira typing time by avoiding small tasks.
Large tasks lead to less shared work, which leads to less shared team responsibility, which leads to a less effective team. How do you know this might be happening? Half-done items at the end of the Sprint and the Team talking about ‘spill-over’ or ‘carry-over’ work.
Key point: The phrases ‘carry-over’ and ‘spill-over’ are not Scrum. They’re signs of dysfunctional Scrum.
How to use Jira so that it causes the least amount of harm? My recommendations are:
RSS feed