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.
Essence of Agile, embracing change. How do we embrace change in Agile? So if we were talking about scrum, for example, how do we embrace change in a scrum environment? Things may change as you go into the scrum the things may happen. The build may not work the way you want it. You have to change, just kinda be flexible, go with it. Yeah, that's right. Yeah, and that's fine. That's fine. That's fine. It's the question. How do I embrace change? But if you think about the way, a scrum process works. Let's look at a scrum process.
So if this was a scrum process there are various artifacts that exist in our scrum process. And the reason I was smiling over, what one of you were saying about shared vision, is that it's definitely part of scrum itself because in scrum, we have various players involved and so we have various team members. And so we would have in this case we would have our developers, our development team. Anyone know who this person might be here? Is that the scrum master? It's the product owner.
Now the product owner is responsible for working with the stakeholders to establish a shared vision of the product. So they all have this shared vision about this product. And that's really what is going on with this interaction. So the product owner is responsible for establishing the shared vision in combination with the stakeholders. And the product owner will own one of the artifacts in the scrum process which is this thing called the Backlog. And the Backlog is, what do we know about the Backlog? Just like a mixture of everything you have to do isn't it to build the product. Yeah yeah.
So the Backlog is the to do list effectively, isn't it? And so the shared vision is captured on this Backlog and all of the items on the Backlog, we call the Product Backlog Items and the significance of the items at the top is what? So this item here as opposed to the one at the bottom, what's significant about the items further to the top? The priority? Yeah, well kind of it's the most valuable in terms of the product.
In a scrum process what we're trying to do is we're trying to always increase the value of the product maximally. So what is going to increase the product value by the most, next? And that's all part of this interaction here. So what can we do next that's going to improve the product increase it's value most next? The stuff at the bottom, you know it might be quite high level. It might not be particularly refined because the product owner and the development team which is gonna include, the scrum master, will refine these requirements they'll get more detail, they'll understand them better. And they will eventually, when they come to do the next iteration they will decide what they're going to deliver next. And that's where the Sprint Backlog comes in.
Now, the Sprint Backlog defines something important. What does this Sprint Backlog do? What's it for? So we've got a Backlog and we've got Sprint Backlog Defines what you're going to release in your next release. Yeah, so what's going into the product next? What's our next increment? Because what we're gonna do is we're going to have a Sprint. And a Sprint would be a fixed duration of, well, let's say two weeks, but typically it'd be between two and four weeks. So a short amount of time.
So the Sprint Backlog would have product Backlog items in it that we know or we think we can deliver in that amount of time. Now, before any of that takes place, we have a meeting to work that out and anyone remember what the name of that meeting is? Planning, scrum planning. Yeah, it's the planning meeting, planning meeting. And that's where we decide what we're gonna do and how we're gonna do it. And then we do our Sprint.
What happens during the Sprint? So what would these sort of funny little red line be? Cause this is another meeting. They're the daily stand ups. Yeah, that's right. It's what we call the daily scrum and the team members will say what they're doing today. What they'll do tomorrow? Any impediments, that kind of thing. So we're constantly getting feedback about our process at the end of this, what do we do? After the two weeks, what happens after those two weeks? There's another couple of meetings that occur at the end of the Sprint.
So once we've done our work we have a couple of meetings. The sign off meetings. Yeah, it is kind of a sign off meeting. It's a review. So what we do is we get the product owner we get some of the stakeholders they come in and they will look at the product that we've produced. They will look at our increment. And that's when they get to give us feedback. So it's been two weeks, have we showed them what we've done and we get feedback and they might say "Yeah, that's what we're thinking." Or, "Actually I don't like the look of it now." "That's not what we expected." So we then get to maybe update the Backlog and encompass any of the possible changes.
We also have, a retrospective where we get to have feedback on our own process on ourselves, where we sit and say, what did we do well? What we're gonna start doing? What are we gonna stop doing? What are we gonna continue doing? So it's very much a process where we're constantly taking the temperature of the product and we're taking the temperature of ourselves and how we work. It's a constant feedback, a constant feedback. Do some work, check and feedback. And then improve, constantly improving. So that's what we're doing.
So when we're saying on the slide, 'Embracing Change'. Well, we're embracing change because we're constantly looking for it. Hopefully you can see from that diagram, embracing change means going to the stakeholders, going to the product owner and sort of saying, "Look, look, how can we make this better? What do you want to do? How do you want to change the requirements and change the priorities so that we can improve, increase the value of this product in the next sprint? How can we change? How can we change to make our process better?" And so it's never accepting how it is right now. It's how can we change it? And that would be the most effective form of any Agile process to embrace change. Empirical as well. The measurement. Measuring, checking, measuring the process, has it been improved? How's it got worse? And then looking to improve when you can. Self organizing teams, empowerment.
So in a scrum process, and this is what I often find when I work with customers, that it's often difficult for customers to let go of a traditional Waterfall process where you would be constantly monitoring how long a developer has taken on a task. When you move over to something like a Scrum process, the time box is for two weeks. It's not how long the cost took. We're not checking, we're not necessarily tracking time per task, we're checking delivery over the Sprint because the ultimate check is whether we delivered what we said we were gonna deliver. And that's what we're doing, is we're committing to deliver what we're saying we'll deliver. And then the other thing, fail fast. Why are we failing fast? What do we mean by that? You want to find issues, bugs defects as quick as possible. As opposed to finding them at the end of the project when you actually hand over to the stakeholder.
Yeah, exactly, imagine you're an engineering company and you go to your stakeholders and say, "We've built the bridge. Do you want to have a look at it?" And the stakeholders say "Well, we wanted to have a pedestrian walkway at the side." You know, it's kind of you want to fail as soon as possible, don't you? You don't want to have to reengineer the bridge or you don't have to reengineer the software because you didn't know until right at the end. That's right. Traditional waterfall.
There are lots of situations where there's lots of compliance required the driver compliance requirements in place, so in a very regulated environment a waterfall is very often essential in those situations. So, you know, the Agile, isn't necessarily the answer in every situation but in a waterfall approach, we would have a set of steps that we would go through, requirements analysis, design, coding, testing, operations. And very often these are driven by documentation and we would do the requirements first the analysis would go next and then there'd be some design.
The problem often comes, and I've certainly worked in this environment. If there's a change here it then has to go through the other stages again. And so change is very often resisted because of the overhead of it. And when you start getting much further down the waterfall, that change is much more difficult. So change very often, isn't embraced in that environment. It's often much more contractual than open but sometimes that is exactly what you want.
The Agile Manifesto which hopefully many of you will already have looked up but it's certainly worth a read. Whenever you're looking at a team or teams where things aren't quite working it's always a good idea to take them back to the Agile Manifesto and to just go through this. And it doesn't seem like it would work, but it does. It's amazing how it does, but I don't think the authors probably realize what brilliant job they did. But there are a few points here that stand out to me, particularly when we're talking about Jira and individuals and interactions over processes and tools.
Now I know this is a course about Jira, and we're gonna talk about Jira but I don't want to allow Jira to overshadow the importance of the Agile Manifesto because Jira is never gonna replace this bit. And if you find that your team are saying, look in Jira, rather than have a conversation, then things aren't working right. That not what Jira is there for. It's not there to replace interactions and individuals talking to each other. And I'll talk about what Jira is there for, what it is good at, but it's certainly not to remove interaction and to reduce the need for it.
Working software over comprehensive documentation. Yep, so what does it do? Well, there it is over there. Go, and have a play with it. We'll demo it to you. You can see what it does rather than here's a word document. The word document tells you what it does. "All right, it sounds brilliant, yeah, I can't wait. I can't wait for that to come alive." So those reviews are so important. Customer collaboration, responding to change. And hopefully from the diagram I showed you earlier those sort of things are jumping out, hopefully, and probably you're already aware of all of this stuff. And I'm just sort of saying stuff you already know.
The Agile principles. I won't go through all of these, but obviously they're in the Agile Manifesto. Welcoming changing requirements, even late. Satisfy the customer through early and continuous delivery of valuable software. I'll just leave that there for now. Does anyone identify any that they find particularly relevant to what they are doing? Anything there that you think should be particularly highlighted or you want to highlight? I think 4 is very important, good communication between the business and the developers. Definitely, absolutely. Yeah, that communication is the key, isn't it? And also the right kind of communication as well. So allow the developers, the developers allow to get on, but the right interactions are also important, interactions that hinder the development team and managing that process is important too, definitely.
Okay, so we go to this slide. The three pillars of Empirical Process Control and Empirical Process Control is really where Jira is at its best. This is where Jira really does come into its own. For a lot of people, Jira is just an incident reporting tool or a requirements capture tool. And that's literally all you do you capture requirements, but what Jira is really there for is to allow you to measure your process, to measure the effectiveness of your process, and to maybe do some forecasting to identify maybe when things are failing, things are going wrong, through measurement. And I suppose also to help with these three pillars.
So, Transparency, Inspection it doesn't help with the last one, that's down to us, but Jira will help with these two. And one of the things Jira does because it's an open tool pretty much anyone can get at it. If we're recording our Agile process. If we're recording our Backlog. If we're recording our process and our tasks and the progress of our tasks. And we're making that available in whatever form in Jira, whether it's via a dashboard or a report, then we can use Jira to make it as transparent and widely available as possible to the wider business.
So we can use Jira as a transparency tool. We've got nothing to hide. If anybody wants to know how things are within our Sprint, they can come and have a look. They can come and have a look at our big screen, which shows our process. We can use Jira to run reports, to run queries and identify problems when they occur. So we can use Jira for these two things but it's not there to completely replace those interactions. And that's the key I would say.
Now using the inspection capability that Jira gives us all of those reporting tools. We may well spot there are blockages in our process that we can remove. We may not realize they are there, but we may suddenly go, "Well actually, why is that taking five days to complete?" And then when we investigate it, we might find out, Oh, well, the reason is because we ordered this part and it takes two weeks to arrive unless you order it on a Thursday, in which case. Or it might be there. It might be the reason it took five days is because it's only Amy who knows how to do Amazon Web Services and she's on holiday and we have to wait for her to come back to do that bit. And so the answer to that might be we'll train somebody else on the Amazon Web Services, whatever it is. Yeah, it's just a general example.
So there may well be things that we can do that can get around their being blockers in the process. And until you realize the block is there you don't realize that you can ask the question to then come up with a solution that will then stop the block happening again. And Jira is brilliant at allowing us to identify those situations. And by having a constant view of that, by running reports, we can spot blockers. We can spot problems. And we can ask the questions that need asking so that we can adapt. And so the three pillars of Empirical Process Control are aided by the use of a tool like Jira. And that that's what I would argue is the benefit of Jira, in an Agile team.
QA is the UK's biggest training provider of virtual and online classes in technology, project management and leadership.