Scrum with JIRA, a Love-Hate Relationship

Steps to bring your Agile project back on track

 

The ideal way to use Scrum is to have the whole team sit in one room. Usually, the Scrum process is employed by using little stickers, and moving them around on a physical board. JIRA makes that easier, but it comes at a cost. This article examines the drawbacks of JIRA and how to remedy them.

 

Within a company, Scrum is usually initiated in software teams, because they are the teams who have to deal with the biggest insecurities in terms of planning. Each software project is a completely new project, even if it is “just” a new version. The software market changes rapidly, hence agile methods are the management method of choice.

 

There’s a glitch in the system, though: hiring people based on their computer skills often comes at a price, namely interpersonal communication. The HR department of a company should take great care to not just hire the best individual coders, but instead, people who can communicate effectively and have a high emotional intelligence (see this internal Google study).

 

One symptom of this technology-heavy preference is that the communication tools are also complex and directed at an audience of software engineers. JIRA is one example and is often used to manage the agile process. But is that really a good decision?

 

First, I doubt you will ditch JIRA just because of this article. I, myself, rely heavily on JIRA. It’s likely that you clicked on this article because you are already using JIRA and you will probably not dismantle JIRA any time soon!

 

In this article, I wrote about the importance of multidisciplinary teams. Tools highly optimized for use with software developers might cause problems when other departments are expected to use these tools, or when creating a team with a mix of people with different specializations. A company has to be careful not to choose the method that is most effective for only part of the company, and instead must look at the company (or a given product) as a whole.

 

What can we do about it? JIRA is a step back in terms of agile, as it disconnects people and makes things overcomplicated. What we need to do is recognize the drawbacks of JIRA and examine ways we can find around them.

 

The gold standard of Scrum is face-to-face communication. I recommend taking another look at the Agile Manifesto and my other article on the subject and then, as a first step, evaluate where you are in the process of becoming an agile company. In what regard do you think your JIRA installation helps or hinders your progress?

 

For example, when creating new stories, JIRA offers you the option to write a summary and a description. This immediately leads people to come up with a descriptive name as the summary, and enter the actual user story “As a User, …” in the description (if at all).

 

I say: the description field should be used only for the acceptance criteria and the “definition of done.” Descriptions should not be needed or even seen by anyone outside the Scrum team. Hence, put that (long, I know) sentence into the summary! Your board will look much more structured if all the stories follow a similar naming scheme. Nobody outside the team will be in a rush to look at your board when it’s filled with technical jargon. And if we take a step back, that is actually what Scrum teaches: Create a board with stickers with user stories! So, why not do exactly that? Having less (e.g., just a sticker) sometimes is better than having 50 customizable fields…

 

Another example is epics. These are used differently from company to company, some call it a “bigger story,” some call it a “feature,” for others it is a “project.” If you are using JIRA, you have to focus on how it is displayed. How would you implement epics when using nothing but stickers?

 

Let us take a step back. In JIRA, epics are basically “super-stories.” Why? Because JIRA offers you a “progress bar” for each epic. (That really reminds me of a pre-planned waterfall project, so I think this feature is rather useless.) Much more interesting is the rather simple feature of color. Assigning epics to stories quickly gives you an idea what the story is about as each epic shows up as a colored banner on the board. With epics, the JIRA board comes alive: you can quickly and easily make visual sense of the entire project–where you’re at, what’s left to do, and who’s going to do it. For example, in the past, I often used “Frontend,” “Backend,” and “IT” as three main epics when working on a pure server project (in a non-agile business environment). On the board, you immediately see what type of stories there are. Once the Scrum process in the company is more integrated, you will of course use user-facing features (as opposed to system components) as epics.

 

Here, I will leave you with a final point. It is a small issue, yet one that annoys the perfectionist in me whenever I start looking at a board of a new company: the “priority” field. In Scrum, there is no “priority” field. First, within a sprint, it is up to the team which tasks to work on and in what order. If you, as a product owner, want to direct the exact sequence of which tasks are built, that’s eXtreme Programming, a topic for another time. Second, even if you take priority into account, who determines the priority? Certainly not the reporter who might have no idea about the business value or the time needed to implement it, yet who is asked by JIRA to fill out the form. And the product owner already sorts the backlog according to priority based on business value and estimation. So, the usual result is that in the JIRA backlog, you end up with two types of priorities, critical and urgent, because every reporter thinks his task is kind of important. The priority even shows up as little red arrows—completely unnecessary and confusing.

Unfortunately, JIRA does not allow you to deactivate priorities directly. There is a little trick, though: In the project settings, in the priority scheme, you create a new default priority and upload an empty transparent PNG file as the corresponding icon. Problem solved and the board looks a little more like a real Scrum board! 🙂

 

How Does Your Team Use JIRA in the Scrum Process?

 

How does your team use JIRA in your scrum process? What are your remedies to JIRA’s drawbacks? Do you ever simply leave JIRA aside and use a pen and paper? Share your ideas in the comment section below!

 

_____

Do you need help with the agile process in your company? Subscribe to our newsletter or contact us for coaching at [email protected]

2017-03-13T21:06:16+00:00

About the Author: