Intro to Agile
Jira and Agile
Jira Dashboard and Tools
Conclusion and Q&A
The course is part of these learning paths
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 firstname.lastname@example.org.
- 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
Anyone looking to improve the way they use Jira to manage their workflows and projects, through the use of agile practices.
To get those most out of this course, you should have a basic understanding of agile and Jira.
Okay, so we're gonna talk about Kanban, and we talked a bit about Kanban already. But one of the things that I want to talk about, and again we probably have sort of mentioned it at the beginning, is how Kanban differs from Scrum. I think we remember what we were saying about the difference. Sprint. It's a sprint, isn't it? Yeah, absolutely. So we don't have that same Time Boxed Sprint. There's an interesting question, why might we limit the amount of Work In Progress? You lose track of it and you may not get it all finished. Yeah, that's it.
So what can happen? And we've all been there. Haven't we? We work on something, we start work on it and we kind of... we do a little bit on it, do a little bit more on it, and then we think, oh, actually I can't do any more on that because I'm waiting for this or I need that, or I don't know how to do this or I need more of the other thing, or I'm waiting for that over there. And so we leave it. Not to wait, but to leave that.
We start in the next one. And whoever is dependent on what we're producing is then also waiting for us. And it can have all kinds of knock on effects, and it may well indicate other problems. It may well indicate there's a problem with our supply chain. It may well indicate there's a problem with our skills base. There may be lots of little kind of symptoms that indicate other issues that potentially could be fixable issues.
So by limiting the amount of Work In Progress and certainly putting structures in place and putting processes in place that allow us to identify when multitasking is happening that can help us start asking important questions.
So Kanban originated at Toyota as a Lean manufacturing process. The goal was to remove waste, improve time to market. Various methodologies to choose from. It... Kanban tracks the items of value to the organization to create something tangible. And the goal is to reduce the time to market. And the thing to think about with Kanban is the sort of chain.
If you imagine a car manufacturing process and we might have various stages in that process. And so this might be welding, and this might be electrics, this is probably completely the wrong order, this might be paint. And if our car is moving through each of these stages, if it gets held up here, then obviously that has a knock on effect here. And I mean it could be being held up by some issue with supply. It could be held up by the person working on this stage not being... being new to it, and not maybe being very quick at what they're doing. But it could be some kind of issue going on here that's causing cars to sort of just build up. And maybe the person that's got the problem, they may do a little bit on this, and they may do another a little bit more on that and a little bit more on that, but there's nothing going this way.
So we're looking at, are we the tasking? Are we working on multiple cars? What's happening in our process? What we want to do is we want to reduce the amount of time it takes to get from here to here. So if we can reduce that time then we're improving our process. So that affects our Lead Time to get through from the beginning to the end.
So Kanban... Scrum works well for Time Boxed delivery. And if you think about the way Scrum operates, what Scrum allows is for an evolution of a product. We don't know, we really don't know what the product is supposed to be. You know least about this at the beginning. So it evolves, it changes.
We say, what do you think about that? We don't like this, we don't like that, let's of change. I know we said we wanted this, but now we look at it and we don't. Can we add this and this and this into it and make it do that? Yeah, sure. That's Scrum. And what we thought we wanted at the beginning isn't exactly what we ended up with. What we ended up with was actually what we wanted, although we didn't know it.
With Kanban, if you imagine we evolved the design of a chair using Scrum and over time, we kept creating it, building this chair until everybody was happy with it. Every two weeks, we gave them a new iteration. And eventually, everyone's happy with this chair, and it looks nothing like the original design, but everyone loves it now.
While Scrum would help us get through that evolution, Kanban would then be the thing we would use to help us build thousands of them in the shortest time possible. So every chair could be built very very quickly by making sure that each step in building the chair was as efficient as possible and didn't have any unnecessary delays. And any delays that were there, we identified them and we ironed out the problems. That's sort of what we're talking about with Kanban. And that's what we call our Value Stream.
What is the Stream? What is our production line that we have to go through? So the three principles in Kanban is: Visualise what you do, so use white boards use Post-it notes, use whatever you need to use. Limit the Work In Progress, don't commit to too much work at once, don't multitask, whatever you start, finish. If you can't finish something, ask why?. Make sure you can finish it. And Enhance the Pipeline, Enhance the Flow.
The next highest item in the backlog is processed next. And process is monitored for improvement, empirical process control. So the Kanban Method is a framework to manage the workflow of software development with a pull system. It's not just a software development method. So you create your initial workflow and then identify waste and try and limit Work In Progress. You might create a Value Stream Map which would be all the stages, all the steps. It's not very clear on that diagram, It's just a photograph. And so, the Value Stream Map would include User stories.
There'd be a Backlog, there'd be a Start and an End point. And then you'd have to define the various stages in your Value Stream Map. What are the stages? Who's responsible for those stages? And then, we would visualize it. Lots of elements that should appear on the Value Stream Map. For each of the stages, you would often include the roles, when you're designing your Value Stream Map which is a nice big diagram. What the Average Working Time would be, what the Wait Time might be, any queues, any iterations. Anything at all that is gonna be relevant and get as many people involved as possible. And just to be clear, it's not a Kanban board that you'd put together when you're doing your Value Stream Map for your Kanban process.
So you might produce something like this. So if there was a Bug Tracking System, one of the steps in the Value Stream Map might be Report the Bug. And then the red is the Average Working Time. And the black is the Average Wait Time. Enter Bug Tracking and then Bug Verification might be the next step. Developer, would be the role here for Bug Fix. And then Test and then Update Bug Tracking. So you can see, each of these stages would be an important stage in our Value Stream Map. And then finally, we get to Close the Issue.
So whatever it is that we're doing, we would identify each of the stages that are important, who's maybe working on it, and what generally would be the amount of time it would take and any Wait Time that might be involved. In order to measure performance in Kanban, we would often look at certain metrics: The Lead Time, which is the span of time from the beginning to the end. The Cycle Time is the amount of time when it started till it completed. And the Throughput is the number of units that were handled in a unit of time.
Now in Kanban, what we're doing is we often use this principle of Little's Law, and Little's Law is working with Cycle Time. And Cycle Time is the Work In Progress divided by the Average Completion Rate. And so that's the time it takes to complete your issue, complete the delivery of your issue. So if we had a Work In Progress of six and we had a Delivery Rate, or a Cycle Time of two, I'm sorry, that's the wrong one. And that's Delivery Rate, two. Then the Cycle Time is going to be six divided by two, which is three.
So that's the Work In Progress divided by the Delivery Rate. So the Delivery Rate being the Average Completion Rate, so the rate at which we're getting through, what we're completing. So that would be our calculation. So our Cycle Time would be three in that case. But look what happens if we increase our Work In Progress. So if we increase the work in progress to 12, that's 12 divided by two, and it increases our Cycle Time.
So having too much Work In Progress increases the Cycle Time. And that's the reason why we try to limit the amount of Work In Progress. So we want to complete more, and work on less. So we... And that's the idea behind Little's Law. And it's the reason why in Kanban, we try and limit Work In Progress, and we're trying and make sure that what is being worked on is worked on to completion.
QA is the UK's biggest training provider of virtual and online classes in technology, project management and leadership.