Jira and Agile Methods - Part One
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.
Now the two Agile methodologies we're gonna use are Scrum and Kanban. And we talked about that, but I'm not going to dwell on those, 'cause we've got a couple of chapters on both of those. Scrum allows for incremental software development. Kanban encourages LEAN continuous development, and ideally it's looking at the elimination of multitasking, but we will... I think that multitasking is a good thing, but when we look at Kanban we'll see how it could be problematic.
Right, now in order to explain one of the previous slides, I did talk about Scrum ahead of time. But you can see that we've mentioned these things, Product Backlog, Sprint Backlog, two to four week sprint and a Potentially Shippable Product Increment. I like the term Potentially Shippable Product Increment, because of course, at the end of the sprint, you're not necessarily going to ship the product. It's not necessarily gonna go live. It's certainly gonna be reviewed. We're certainly going to get feedback. We want to fail fast, but we don't necessarily put it live, so, you know, we want to encourage change.
What we're gonna do then is we're going to have a kind of breakout session, and you're going to do this activity, this Agile activity, so teams of two to three people. But really what we're doing is we're going to identify the main members of the Scrum Team, write them on a Post-it note, or type them on a chit in the chat window, or however you want to communicate. And also we want to talk about the main roles and responsibilities. And then when we come back together, we'll just get a few of you to just to talk about some of the Scrum roles.
Okay, welcome back everybody. So what have we got then? Who's gonna go first? If we have the first team, if we say, what about Craig, Carl, Craig, and Duncan? What did you come up with? Which Scrum team members, member or members have you identified? Do you want me to? Yeah, yeah, yeah yeah. All right, yeah. (laughs) I think that's fine. I'll have to try to remember it now, 'cause I closed the breakout session. We had Developer, Tester, Scrum Master and... Product Owner. Product Owner, that was the one, yeah.
Okay, so which one do you want to talk about? So what, just pick one and which, what do they do? What's their role on the team? Well, I think the Tester. (laughs) We went with the best team , which is the Dev. The Dev Team, pretty much, is just that obviously making the product, making things happen. They'll take the ticket; they'll have a daily Scrum meeting. Pick a ticket, whatever the tasks they're up to that day give an update, and just create the products, iteratively. Cool.
So the Development Team, the developers themselves are, well hopefully, cross functional, so they'll have multiple skills, so they'll have coding skills, maybe testing skills, maybe some analysis skills. Maybe they'll have one or two or maybe three of those skills, but ideally the team itself together will have all of the skills necessary that will allow the product to be developed, absolutely.
Okay, so what about Ian, Joanne and John? Who are you gonna pick? I'll do it. Yeah. It's Ian by the way. Uh-huh. Yeah, so it's very much similar thing, Product Owner, Scrum Master, Developer, a Tester, and we put a Trainer in that as well, in case there's any training material that needs to come out as part of this. Okay, and so which one of those roles do you want us to talk about? Um, I dunno, should we say... Let's say the Scrum Master. Scrum Master, cool, yeah. Yeah that, so Scrum Master, again, well all of our people, we kind of had similar traits for all of them, so a lot of this covers everybody, but the Scrum Master needs to plan, so they need to have good plannin' skills.
They need to be able to communicate, so, you know, communicate with members of the Scrum, and then, you know, the Scrum Master and then, maybe, say Product Owner and maybe some Senior Management Team. If things need to be presented to them, they need to be able to review what's goin' on. They need to be able to, they need to have a bit of testin' skills. They need to have a bit, you know, awareness of code, sort of keep everything on track, be able to plan trackin', and make sure that we're hittin' where we should be hittin'. Cool, yeah, sounds good.
And what about Phil, Simon, and Steven? Well, I'm the one that took the notes, so perhaps that'll... I've got them in front of me. Yeah, it sounds good. So we'll just talk about Product Owner yet. So we didn't have a test or nothing, and that could affect the fact that there wasn't a Tester in our breakout group. Maybe also we got missed out the test. (laughs) Yeah. But we had the product owner, so we thought they'd be there. There was a tester there Phil. There was. Sorry, sorry Steven. But I would say testing's part of the development process, so I was just like... Yeah, so the role of Developer, what we're looking at is Development Team members would be cross functional, so that role would be, it wouldn't be a role in itself. It would certainly be, it would be a capability that one or more of the developers would have, yeah.
I feel awful now, I mean, I was taking notes for the team, and I forgot that Steven was the Tester. My bad. (instructor chuckles) But for the Product Owner we said they, because they're in charge of defining what the products we shipped is, then they would probably be best placed to decide, looking at the backlog, which were the most valuable items, and then help to allocate them to the Scrum accordingly, because they know what they want to be built first. Right, yep, yep that's it. And the Product Owner is in charge of the talking to the stakeholders and working on the shared vision, and ultimately they're responsible for the backlog. That's right, yeah.
Cool, okay. And Steven, Tiz, and Viv, if you wanna talk about the stakeholders. Yeah so right. Tiz feel free to chip in. We defined the stakeholders also as product owners who share the shared vision with the Product Owner, and they are perhaps subject matter experts who help define issues with the Product Owner. So whatever field the product is, is in her name, that they would have some knowledge to be able to flesh out and design the requirements and develop it right. That's right.
So basically, in addition to what we pointed out, and others have pointed out with a sense, would be the Product Owner, the Scrum Master and Developers. Could there be systems or actually current development testing. We also think that there should be, actually, a Stakeholder as part of the actual group who actually looks at, reviews, and, say that, if there's an issue, they can then, we can then fail fast to identify it then as well as we could, then correct it and get to move on. Okay, cool. Yeah, sounds good.
So what we often find there, in the Scrum process, the Product Owner needs to be empowered themselves. So yes, they talk to the stakeholders. They create the shared vision with the stakeholders, but they need to be able to make decisions about the product backlog. They need to be able to talk to the Development Team. They need to be able to feel empowered that they can make those decisions on behalf of the stakeholders. And these, the Scrum process very often fails as a result of that, the Product Owner not being sufficiently empowered to do that, so you sometimes find that.
The Scrum master also, the other thing you often find is, the Scrum Master is used as a kind of, sort of team leader, and that, really, the Scrum Masters position is to ensure that the Scrum process is followed properly and adhered to, and they're not there to be a team leader. They are there to help the Development Team resolve issues, to remove impediments, and to ensure that Scrum is followed correctly. They also evangelize to the wider business as to the benefits of Scrum within the business, but just using a Scrum Master as kind of a team leader isn't really ideal in the process.
So you often find that the issues of Product Owner and issue with Scrum Master can often, those roles can become blurred, and you can get Project Manager and Team Leader being substitutes, and what I've certainly found is that that can be problematic. Okay, right, so that's really good. Thank you for that. That's all really interesting.
QA is the UK's biggest training provider of virtual and online classes in technology, project management and leadership.