You can set up Jira to reflect how your team works or to influence how it works. Here's what I mean. When a team starts to use Jira, the first instinct is to configure it to match the processes and methods and language of how the team currently works. This makes sense because you want your team to go into Jira, especially early on in your use, and see something familiar. Issue types named for real work people do and workflow steps that reflect how actual work gets done on your team and field names that reflect names of things your team recognizes. 

• Priority
• Resolution
• Affects Version(s)
• Fix Version(s)
• Component(s)
• Environment
• Estimate
• Log time
• Development
• Agile

No. They will not. This list of fields would scare away just about any team other than a software engineering team. Yes. Jira should be set up to reflect how your team works. 

On the other hand, if you only configure software to reflect how a team currently works, you will never stretch that team or otherwise help that team improve how they work. At least not in any meaningful way. You must also organize Jira to influence how your team works. 

Let's look at two examples:

To reflect

Consider an agile team running a daily scrum. A common daily scrum meeting is mostly about going around the room while each person gives an update on the three questions:

1. What did I do to advance the sprint yesterday?
2. What will I do to advance the sprint today?
3. What is getting in my way?

In this mental model, the meeting is about what each individual person is doing. Even if there is a lot of teamwork going on, the meeting is still about what each person is doing. If a team's meetings are run this way, and many are, that team might have a Quick Filter for each person on the team. So that when it is someone's turn to go, the scrum master clicks on the Quick Filter for that person to show that person's issues on the board.

"OK, Kira. What is your update?"

Kira's issues are displayed on the board, and Kira gives her update. 

This is a good practice, actually, because Kira should focus her update on the issues that are in some sort of "in progress" or recently "completed" status. If Kira wanders and talks about meetings she has scheduled or talks about unplanned, urgent work that is not on the board, the scrum master can intervene and bring Kira back on track.

That is good scrum practice. 

Since that is how most (well, many) daily scrums work, this is also how many scrum boards are configured, with an orientation towards the work individuals have assigned to them. 

This is how Jira can be set up to reflect how a team works. 

To influence

What if we have a belief that this "person-orientation" is too focused on the individual and not enough on the team or on the project itself? What if we want to influence the team towards a new orientation (way of working)? We could change how Jira is configured. And we could do this with a simple change that focuses not on Quick Filters, but on Swimlanes and configure swimlanes on the board to show issues by due date. 

Consider the three questions of the daily scrum:

1. What did I do to advance the sprint yesterday?
2. What will I do to advance the sprint today?
3. What is getting in my way?

If we really wanted to focus our discussion on advancing the sprint (the project/work), we could create a swimlane to show issues due yesterday and a swimlane to show issues due today. Then, a third swimlane for all other issues. Your JQL might look like this:

Issues Due Yesterday: 

duedate <= -1d

Issues Due Today:

duedate = startOfDay()

All Other Issues:

Use the default rule "Everything Else" 

You might be thinking, "How does this influence (or change) how we would run our daily scrum?"

This is how. 

When you show the board during your meeting, the top swimlane will show all issues due yesterday no matter who the issues are assigned to. Ideally they would all be in the "Done" workflow status, but of course not always. The point is that this swimlane shows all of the issues that "the team" committed to finish yesterday. So, the scrum master can now ask the team, "What did WE do to advance the sprint yesterday?" Now the team can discuss those items, and do it as a team.

When that discussion is done, the next question for the team is, "What will WE do to advance the sprint today?" The team then focuses on the issues listed in the second swimlane, and discusses what everyone will do to complete those tasks today.

To reflect or influence: That is the question  

A simple configuration change in Jira can influence how a team works, and this is the way teams continuously improve. Of course, you will run into resistance to changes like these, however small. That is why you will need the leadership necessary to see, make, and reinforce these changes until new habits are formed.  

You may begin your journey with Jira by configuring it to reflect how teams work, but you need to progress to a place in which you can configure it to influence how teams work.

If you would like help configuring Jira to influence how your team works, you might want to talk to us. If you are not ready for that, watch this video that shows how we helped Qantas set up and run Jira to help with their digital transformation.