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

What is Agile?

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
What is Agile?
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

Right, so introducing Agile. First part, let's have a look at this. So we're gonna explore the essence of Agile and we'll talk a little bit about Agile, and Jira as well.

So, first question, what is Agile? What do we mean by Agile? What is it? I think it is a sort of interactive development process where you work with the customer or client you're developing for rather than sort of doing it the old fashioned way where you might gather your requirements, go away, spend two years writing software and then present it as a finished article. You regularly go back to them, present prototypes and then, you know, tweak those, until they get a sort of a shared vision of how it should be before you finish it. Wow yeah, I like some of those words. That sounds really good. A shared vision. Shared vision. That's nice. (man laughing) I love that, yeah, that's really good.

What else? Agile is the manifesto, isn't it? It was brought in basically to deal with the complexity of software development as software becomes more and more complex, and we have different specialties that actually contribute and integrate into software development. It's hard for all of that knowledge to be harbored within one individual or just a small group of individuals.

Agile has allowed the specialists within that area to actually create a team in which they can then iteratively, then improve a piece of software, to ensure an outcome that the user will actually realize at the end of it, rather than projects done halfway through. Yeah, I'm loving this.

So, what's the deal with the iteration and why? I mean, we've heard that word twice now. And it's been repeated a couple of times within both speakers' talk so, the iteration, why iteration? It seems quite important to what you're saying. Well, I think sometimes because customers or clients, users or stakeholders, however you wanna term them, don't always (indistinct) all the benefits at the start of a project. And sometimes, you know, by slowly adapting and through iterations with development, a better idea, and which actually suits the overall outcome is perceived by those (indistinct) and improvements. Yeah.I mean, so everybody else then.

So, that phrase, "They don't always know." I mean, we don't always know. The customers don't always know. We don't always know as much as at the beginning as we know halfway through or towards the end. We don't always know exactly what it is that we're after. We, sometimes we don't know. Sometimes we don't know what it is that we really need or we really want until we understand much more about it. And when is it that we understand least, is usually at the beginning, isn't it? So definitely.

Now, I think we've kind of talked about some of that already, but Waterfall methodologies. How is that Agile? I mean, what differences are we looking at here between Agile and Waterfall? Where does that come in? So, let's have some different speakers to the previous two speakers.

So, who else wants to add into this? So Waterfall and Agile? Well the obvious one obviously with Waterfall everything is documented. Quite detailed, and then obviously the development teams go away and and then you come back at the very end. Whereas Agile, there's not much documentation. It's all built around meeting face to face meetings and they can play it back to the stakeholders and getting input from the various elements of the Agile team and just continue to just access, awaken and breaking it all up into small chunks. But there's a huge lack of detailed design documentation with Agile as opposed to Waterfall. Okay.

Okay. And disadvantages, advantages, disadvantages. What are we thinking about there? What happens with, what would identify as advantages and disadvantages? The advantage is that you can spot potential problems pretty easily, you can make changes. You know, it's one of the requirements, it's gonna be difficult to meet. Or you know, those type of things flush out early. You know, there's a better way of doing something. Again, that's kind of identified and worked on the easy rather than as you go into one of the task phases or something at the end with Waterfall.

The disadvantages from previous experiences, you struggle to use Agile, if you're not on the same site. I found it difficult when we were, you know we have developers in India and the BEAR program managers et cetera, in the UK. We always found it kind of difficult with or without that face to face rapport, this was pre video call technology. So that may no longer be an issue. Okay.

Okay. So what we're kind of saying is with certain Agile frameworks, what we're often talking about, we're often talking about creating increments that we can get feedback from. And so, and that is helping us, that is helping us know and fail fast. So we're kind of understanding very quickly when we're not quite where we need to be. Whereas maybe with a Waterfall approach we've got a lot of upfront design and then it's more like stopping a juggernaut. It's quite difficult to stop it in process.

Cool, okay, and we've got two main ones that we're gonna talk about on this course, Scrum and Kanban. And because we're gonna talk about them, I'll ask about Scrum, and then I'll sort of ask a different question around Kanban. So Scrum, what would you say? Let's have a different speaker here.

So Scrum, what's your discerning of Scrum? So talk to me on this. What is Scrum? And you know, what happens in Scrum? Why is it such a popular Agile methodology, Agile framework? They say methodology, it's not really a methodology. It's a framework, isn't it? I've known Scrum as just like a daily chat.

Get up talk about what you're doing that day, what you plan to sort of work through. About 15 minutes ish. Okay. It's a way in which you can actually write down work into bite sized chunks and beans and it provides some more transparency. And if things become more, if time becomes limited, then you can count or sacrifice (indistinct) functionality but is not, you now so important. And so you have that level of flexibility. Okay, yep that sounds good.

So with Scrum, what we're doing is we're saying, "Well, let's have a fixed amount of time," yeah. "We've got a fixed amount of time, let's guarantee we're gonna deliver a level of quality every time." So we're gonna identify what the level of quality is, and what definition of complete is. And then we're gonna say what we're gonna do in that time, and we're going to identify what we can deliver in that fixed amount of time. So it's the, what we deliver that varies, not the quality or the time. And as we get better at Scrum, we get better identifying what we can deliver. And we deliver increments that we are getting feedback on, and that's ultimately what we're sort of doing. And that feedback that continual feedback, in terms of what we're producing, and in terms of our process, is our key features of what we're doing. I'm gonna come up and see that.

So last question here, before we start going through some of this, some of the detail in this chapter. Does anyone know how Kanban is different to Scrum? I've only heard of Kanban in relation to the Kanban board. I didn't realize it was a framework of its own. Isn't Kanban more like a never ending isn't it? It's more like a so in our experience it would be a team who does just one function and it's continual and never ends. It's not a project with a start and an end features. It's just, you have a backlog and things are just fed into it. And it just rumbles on continues. Yeah, I mean that's right.

With Scrum, you know, you have this idea that a Sprint, and a Sprint is a time boxed set of work that you work on and then you deliver. So you might have a two week Sprint, and everybody works on this two week Sprint. And then out of the two week Sprint comes some form of deliverable product. And that is then reviewed. And then we do another two weeks Sprint.

In Kanban there isn't this idea of a Sprint is a continual process. Imagine it actually came from car manufacturing. So you imagine a production line producing cars continually. It's along those kinds of lines, but we'll come back to it. Okay, so let's just, we were just talking about, you know, what do you know about Agile, and Scrum, and Kanban, that kind of thing.

I want us to just look at some detail around that. Because Agile is an umbrella term. And it catches a number of Agile frameworks. And a framework isn't a methodology, and a methodology will tell you, "You need to do this, you need to do this. And then you do need to do this staff. And then you need to follow this step."

Frameworks are guidelines, principles, that you would adopt. And so the various Agile frameworks that are available, some have features of (indistinct) some you may be familiar with. So Scrum is the obvious one, Lean Kanban. Anyone's come across SAFe? (indistinct) Yeah, it's a kind of way of scaling Scrum across multiple teams. So you can you can really kind of, if you're doing a very big project you can have multiple Scrum teams all working on the same project, and coordinate that and in a much more effective way.

So it's kind of scaled Agile framework. Extreme Programming. Anyone come up with that? I know a couple of you mentioned Extreme Programming. Anyone come across that before? Extreme Programming? Yeah, I mean again, a set of principles. There are a set of techniques that come out of Extreme Programming. Things like pair programming, test-driven development. These kinds of things that can really drive the development, but definitely techniques like pair programming and test-driven development can really improve the quality of the code, and the effectiveness of the development.

So sometimes I kind of an amalgam of Extreme Programming and Scrum can take place where you sort of do taking techniques from Extreme Programming, and using them in Scrum. So sometimes you see hybrid with these things working together.

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.