We Scrum but…

We have to use JIRA

A Kick in the ScrumBut — Episode 3

So is your Scrum Team using JIRA? I have some questions (❓) for you to ask during your next Retro.

First, some small disclaimers:

1. This is not going to be a PRO or AGAINST assessment of using JIRA as a Scrum Team.

2. I’m using JIRA as a ‘use case’, as this is the #1 used software development tool for project and issue tracking applied by Agile Teams (as Atlassian states). Even though I am using JIRA as a use case, feel free to replace JIRA with whatever software your team is using in context to this post.

3. Although JIRA is used by many Agile Teams, using JIRA doesn’t imply that a team is agile. Using JIRA doesn’t make teams agile either; no project or issue tracking tool can make a team agile.

Consistency reduces complexity

I’ve learned that in many companies JIRA is prescribed to Scrum Teams. Many follow the herd, and the widespread use of JIRA is often mentioned to be the main reason why JIRA gets prescribed.

It’s considered to be a rich tool with popular features, metrics and integrations used to manage Scrum Teams administration. It can provide both consistency yet leave room for flexibility. JIRA allows for variations in configurations per team. Each team could have its own Sprint cadence. It provides lots of ready to use metrics and integrations to numerous other applications. It’s a means to keep track of history and to provide transparency and to justify liability. It can also used for time tracking. But please don’t get me started on time tracking just yet; that deserves its very own rant.

Now consider this from the Scrum Guide (SG):

• “Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.”
• “No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality”
• “Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.”
• “The Development Team works to forecast the functionality that will be developed during the Sprint.” — the official Scrum Guide

Consider raising these questions during a Retro:

• ❓“Is the JIRA configuration or Sprint cadence prescribed by members outside the Scrum Team (on how the team should do its work)?”
• ❓ “Does the Development Team consider the configuration to be optimal in the way it chooses to organise its way of working?”
• ❓ “Who really shapes and owns the Sprint Backlog?”
• ❓ “Who is allowed to create Product and Sprint backlog items?”
• ❓ “Does JIRA come with a prescribed Sprint length and start and end date?”

What about Transparency?

The Scrum Guide states that the Scrum Team must make sure that the Product Backlog, Sprint Backlog and the Increment is transparent. This means that everyone shares a common understanding of what is being seen and that what is being seen is actual.

• ❓“Does the Scrum Team consider JIRA to be the preferred way to make progress transparent?”
• ❓“Does the Scrum Team govern who may inspect what elements of the Product Backlog and Sprint Backlog?”

What about monitoring progress?

The Scrum Guide states that:

• “Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism.”

JIRA provides many ways to create projections and forecasts and to make progress visible. The Scrum Guide continues with:

• “In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.”

To me this is one of the most important statements in the Scrum Guide. Scrum Teams should be very careful about the way it applies projections, forecasts and progress indicators. The Scrum Team should know that the Product Increment itself is the primary progress indicator!

The Product and Sprint Backlog need to be as technical as necessary for the Scrum Team to effectively administer and execute its work. Only they can determine how this can best be managed.

Product Backlog, Sprint Backlog, forecasts, projections and progress indicators in JIRA are all artifacts. So raise these questions:

• ❓“In order to inspect progress, what is primarily being addressed: these Artifacts or the Product Increment?”
• ❓ “Do these Artifacts cause a reduction in direct collaboration and does this inadvertently lead to a reduction in transparency?”

What about complexity and waste?

JIRA has many features, metrics and integrations to benefit progress tracking, planning and forecasting. A Scrum Team should always consider and inspect if these are truly adding value to the product and its development.

• ❓“Do these include needless ceremonies and rituals that introduces waste into the process?”

Remember these principles from the Agile Manifesto:

• “Individuals and interactions over processes and tools”
• “Working software is the primary measure of progress”
• “Simplicity — the art of maximizing the amount of work not done — is essential.”

A Scrum Team could ask itself for example:

• ❓ “Are parts of JIRA used by others outside the Scrum Teams as alternatives to inspecting the actual Product Increment during Sprint Reviews?”
• ❓ “Are certain configurations in JIRA mere rituals that add more complexity than value to the Product Development process?”

What about collaboration and communication?

JIRA supports many ways for teams to digitale collaborate and communicate. However, digital collaboration and communication is often far less effective than direct, face-to-face, personal collaboration.

Many will argue, and much has been researched, to back up the notion that a whiteboard is the most effective tool to use in the workspace (as a means for teams to collaborate and align). In my own experience, using a whiteboard really promotes a lean, hands-on and visible approach. It is flexible and the Scrum Team had much more control over its use. A team may add whatever it feels valuable to add, on-the-fly. It is far easier to collectively update and discuss what’s on a physical board and it stimulates members to get together in person.

I’ve seen a lot of ridiculous setups where teams would sit impatiently and inattentively around a table, with JIRA on screen, cringingly watching one person follow instructions to update the board…

I’ve seen Daily Scrums during which Development Team members would simply refer to updates on certain tickets by calling out ticket numbers.

• “I am working on ticket number [who knows what]” …

I’ve also seen teams use both JIRA and a Whiteboard in the workspace effectively together, where the whiteboard keeps track on progress towards the overarching Sprint Goal and notes of anything the team might find meaningful.

I’ve seen developers reply to comments in JIRA tickets to each other while they were sitting in the same room together. In any case, JIRA shouldn’t be an excuse to not collaborating and communicate directly.

Conclusion

What is comes down to, is that the decision on whatever tools and configurations to use, and how to use them effectively, rests with each single Scrum Team. They should be free to experiment and inspect/adapt. This is even the case when multiple Scrum Teams work on a single product.

Although sharing similar tools and approaches may help collaboration across Scrum Teams (consistency reduces complexity), it is still up to the Scrum Team itself to weigh the pros and cons.

Project tracking tools can be applied for either good or evil.

Next episode: