1. Home
  2. Training Library
  3. Business Management
  4. Courses
  5. Jira Essentials for Agile Teams

Creating and Customizing a Kanban Board

Developed with
QA

The course is part of these learning paths

Applying AGILE Techniques to Build a DevOps Practice
course-steps
6
certification
1
description
1
DevOps Playbook - Moving to a DevOps Culture
course-steps
7
certification
2
lab-steps
1
description
3
play-arrow
Start course
Overview
DifficultyIntermediate
Duration4h 1m
Students65
Ratings
5/5
starstarstarstarstar

Description

This course is designed for users who are already able to create, update and search for issues in Jira but now want to understand how to use Jira to control, manage, and maximize the effectiveness of their agile projects. We will look at using Jira in Scrum and Kanban projects and how Jira can be a powerful aid in the pursuit of empirical process control.

If you have any feedback relating to this course, feel free to contact us at support@cloudacademy.com.

Learning Objectives

  • Review Agile, Scrum, and Kanban practices and how Jira can be used in conjunction with them
  • Understand how Jira can be used to capture Epics, Stories, Tasks, and Acceptance Criteria
  • Understand how to use Jira to manage Scrum and Kanban projects
  • Learn how to use the Jira dashboard and tools

Intended Audience

Anyone looking to improve the way they use Jira to manage their workflows and projects, through the use of agile practices. 

Prerequisites

To get those most out of this course, you should have a basic understanding of agile and Jira.

Transcript

Let's create a Kanban board. So we can select Kanban software development. And I'll show you a few interesting things about columns for Kanban boards and also for the Kanban backlog. And we'll do this altogether. So we'll do this as a demo. So let's create a new project, but what I'm gonna do, and I'll do it on both servers. I'm gonna create a Kanban project based on some sample data.

So in Jira, what you can do is when you create a project, there's that link at the bottom that allows you to create a project based on sample data. So I'm gonna do that, and I'm gonna call it my Kanban project. I'll do the same thing on the other server as well. So create project, create sample data, my Kanban project. Okay, so this Kanban project has been populated already with a whole bunch of data, which you can see.

A Kanban project as it is at the moment, you could see the Kanban board is driving everything. The Kanban board has got the backlog on it, and then it's got a number of different stages. So it's got selected for development. So that good for development, a sort of like a sprint, but it's a sprint that never ends. So selected for development are all of the things we're gonna be working with, the backlog is the list of issues. But these are the things we're gonna be working on next. And the team will choose from this column.

So the backlog are all of the items to be worked on, but these are what we are going to work on next. So this is where we can control our priority. So that's it for development. And then it's very similar to what we were looking at in Scrum. We've got the in progress, we've got the done and your value stream map is what will tell you what these other columns should be. And if you go to your board, so this is called my Kanban project. My Kanban project.

So if you go to my Kanban project and then click on board and configure, just like with this Scrum project, you can change the columns. If you go to the column section, you can change the columns to include all of the columns that are gonna be relevant in your process. So I literally just add a new status, so I could say in test. So that's it. And it's been added here, and then I could add a column. I could have just added it as a column, to be honest. And there it is. Yeah, sorry, I should have just added it as a column in test. And there it is.

So I have now added a new part of the flow. So if we've done a value stream map, we could have used that as part of this process. If I go back to my board now, you can see that we've got in test. So it's that. Anyone know why we've got one of these columns in orange? Allows a maximum of one thing, we've got two things in it. Yeah, that's exactly right. So you can see that we've got this max one limit on here, and this is why we're trying to limit the work in progress.

So if I go to the board and configure the board again, we can put column constraints. So we exact issue count. And then you can set the minimum column count and the maximum column count. So in progress is basically saying, well, why aren't you gonna have one person working on this? So we've gotta put a work in progress limit of one. Now it doesn't stop developers or engineers moving an issue to in progress, but it tells us that it's happening.

So we can see what is potentially multitasking, actually happening. Try that for yourself, try and create a Kanban project. And then in your Kanban project, you might need to, in your Kanban project you can go to board and configure, and then you'll need these both column constraints, it might say none, so issue count. And then you'll be able to add a column constraint into your Kanban board, go back to your board. And then that will limit the work in progress, or at least allow you to identify when there is the potential for people exceeding work in progress.

So if you think about Little's LAW and you think, well, we don't want to exceed that level of work. We don't want people multitasking. If we've only got two testers, we can't be working on three things, then it's a little more complex than that, but that's the sort of idea. So that's why we might set work in progress limits.

So what you might do is set initial limits and then resist the temptation to increase work in progress limits when the team keeps hitting it. Use training to improve efficiency, identify reasons why the work in progress is being hit. So it's an opportunity for analysis and an opportunity for improvement of the way the process works rather than for you to tune the value. So that's Kanban boards with work in progress limits.

Another thing that's useful to do, which a lot of people who come from a Scrum background quite like is to take the backlog away from the Kanban board. So if you go to board and configure. It's a little bit fiddly the way this works, but what you can do, you don't just say it's Kanban backlog it's on the left hand side here. If you kind of pick up this backlog item here, you can drag and drop it onto the Kanban backlog like that.

So what I did was I picked up this backlog status in this column and I dropped it into this Kanban backlog section. So it's here. And now when I go back to the board, you notice that the backlog column has gone and we've only got selected for development. So the backlog is no longer part of the board, but if you look on the left hand side, we've got the gender blocks icon and the backlog is now accessible from there, just like it was on Scrum.

So it's a more traditional kind of Scrum design where you've got a backlog and a fixed selected for development. So this is where you can move things from your backlog into what's going to be worked on next. So it's much more kind of Scrum like, it's just that selected for development is a never ending thing. It's a sprint that goes on forever. You just keep adding to it.

Just as we saw with the scrum board, you can organize your Kanban board using swim lanes. And I'm here, we've got a couple of swim lanes, we've got expedite and everything else. Expedite is set up to only show issues that have a high priority. And you might tell developers anything that appears in the expedite swim lane must be worked on before everything else. And that means you can segment the board. It could be segmented by component. Well, yeah, you could segment it in any way that you think would be effective.

You might have some developers working on one swim lane, some developers working on another swim lane. However, whichever way would be best to organize it for whatever you're doing. So the swim lane cuts across the Kanban board. And if you go to your board and configure, there's a swim lane section, which is where that is all set up, and that's where you can set up your queries. So you're sort of saying expedite contains only issues where the priority equals highest. And the swim lane is based on query.

Now if you remember our Scrum board, the swim lanes were based on user stories. The board itself is based on a query. Now by default, the board will always use the issues that are part of a project. But if you want to, you can change the query that retrieved the issues that populate your board. You just say, add it, filter query, and then you can change what that query actually is.

So you can use this tool to change the query parameters, change, the statuses are gonna be occluded. And then you can save it for later. So it is possible to do that. You can change the filter query that's used to drive the board. That can make it quite flexible.

About the Author
Students2041
Labs19
Courses16
Learning paths6

QA is the UK's biggest training provider of virtual and online classes in technology, project management and leadership.