This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams.
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.
JIRA · The on-premise or cloud software Jira by Atlassian is one of the leading ticketing systems available. Beyond a mere ToDo list, it provides administration functionality for projects, Scrum and Kanban boards, custom workflows, custom screens, user rights management, plugins, and third-party integration. The name itself stems from Bugzilla, the software Atlassian originally used for bug tracking. They began calling it by the Japanese name for Godzilla, “Gojira.” When they later developed their own bug tracker, they just dropped the Go—hence Jira! (source)
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 is 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 What Google Learned from its Quest to Build the Perfect Team [Duhigg, 2016]).
We’re a culture that loves technology—sometimes to the exclusion of working with people. As a result, our communication tools tend to be complex and directed at an audience of software engineers. This also applies to Jira, which 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 book. I, myself, rely heavily on Jira. It is likely that you are reading this book because you are already using Jira, and you will probably not dismantle Jira any time soon!
In the previous chapter, 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 them, 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 around them.
The gold standard of Scrum is face-to-face communication. To what extent is your team practicing this? I recommend taking another look at the Principles Behind the Agile Manifesto [Beck, 2001],What Google Learned from its Quest to Build the Perfect Team [Duhigg, 2016], and “Our Scrum Is Special” 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 gives 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 if it is filled with technical jargon. And if we take a step back, that is actually what Scrum teaches: Create a board with stickers describing user stories! 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 first have to focus on defining an “epic,” then on how it is displayed. How would you implement epics when using nothing but paper stickers?
In Jira, epics are essentially “super-stories.” Why? Because Jira offers you a progress bar for each epic. (As this really reminds me of a pre-planned Waterfall project, I find this feature 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 is fully adopted, you will of course utilize 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 Jira board of a new client: 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 is eXtreme Programming (XP), 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 prompted, by Jira, to fill out the form (better to leave it empty than fill in a meaningless bit of information that will just cause more work for the one reading it). And the product owner already sorts the backlog according to priority, based on business value and estimation. 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.
BACKLOG · The backlog of a project is a list of stories prioritized by the product owner according to the business value of each (estimated by the stakeholders and product owner) and complexity (estimated by the team). Keeping a clean backlog is key to success: it is not an idea graveyard! You can move all those nice-to-have stories to a separate list.
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 can 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 your Scrum process? What are your remedies to Jira’s drawbacks? Do you ever simply leave Jira aside and use a pen and paper?
