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

Release Planning

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
Students35

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

So the beginning of a project, you may well do this, you may well do release planning. What's the release plan for the product? What are the main features and when will they be delivered? This may be something you can draw out of your user story mapping. In JIRA what we would do, if I go to my list of projects, there's my demo SCRUM project. Earlier what I did was I defined a bunch of epics. I am at processing Item Management.

Now this time what I'm gonna do is I'm gonna create versions. So I'm now on my Backlog, and I'm going to Versions and I can create a version map or a set of Versions. So I could say Version 1, and I can indicate when the release date needs to be for Version 1. Let's say it's the 30th of September. And then let's do Version 2. (typing) You could call it Release 1 and Release 2, if you wanted to.

So now what I might do is I might say right, well, what does Release 1 look like? (typing) We need choose product, we need add to basket. We may... Now these are real stories that I'm adding. Which is just a simple way to do it. Obviously I could do it like this. I could press the Create button, choose Story, and then do it like this. But I'm just using this fast way of doing it. So add to basket. (typing) Now this is where I might do my Version.

So I might say, okay, so Version 1 needs to have a View Products Story. It needs to have an Add to basket, Place Order, and a Pay with PayPal. Take all of that, that. Okay. So that is Version 1 of my product. Version 2 hasn't got anything in it. But Version 2 could include Pay with Credit Card. There we go. So that's the only thing that's in Version 2, Pay with Credit Card.

So what we're doing is we're creating a set of Versions and maybe we could organize Version 1 and so say well, Choose Product, Add to basket, Pay with PayPal, Place Order, and then what we would do from here, I have to delete that sprint. What we would do from here now, is we would say, let's create a sprint, our goal, which is very important that you identify a sprint goal, so (typing) Deliver Shopping Basket, something like that. The duration gonna have a two week sprint. And we've created our sprint with our sprint goal.

You want to have a much clearer sprint goal than that. And then we're gonna say right, well, we think that we can deliver a certain number of items but we don't know what we can deliver. How do we work out what we can deliver? What would be the process that you would go through? What would be the next step do you think? So we need to do a bit of backlog refinement on this. What would we need to do now? Would you wanna put estimates against each task? Yeah, that's it.

So we need to estimate wouldn't we? We'd need to sort of we need to look, we need to check whether it met our definition of ready. So when you look at the... Let's look at the Description. No it doesn't really meet our definition of ready, does it? So it fails, but let's imagine it did. We need to give an estimate. And you can see that there is an Estimate field here. I'm typically we might use Story Points. What our teams use is they're almost Fibonacci numbers, they're not quite, but they almost are.

They would use a set of values and every member of the development team would take a look at the thing that's being estimated, so they would look at the documentation, they'd look at the scenarios, they look at how complex it is, and then they would then all hold a set of cards similar to this, and then they would pick one and hold it out. And they the group would come to a consensus as to what the value would be in terms of complexity, so increasing complexity.

So we've now estimated, Choose Product, Add to basket, Pay with PayPal. Method definition of ready, we reckon we can estimate it, got enough information. And now this is when we work with the product owner and agree what's gonna go in our sprint. And based on our previous performance, I know that we can deliver from our previous performance, I know that we can deliver about 21 to 22 Story Points. We've done it before, we have delivered 22, 23 Story Points before.

So if history is anything to go by, I know we've got the same strength of team. We've not lost anybody in the next two weeks, then we can probably do about 22 Story Points again and see if our estimation is consistent, which hopefully it is. So we're gonna do Choose Products and Add to basket. The top of our backlog, the product owner says they'll have the most value to the product.

Next. The stakeholders think they're important. And that's it. Really, before we decide we're gonna do those, we should really now break them down into sub-tasks. So like I said, before you break everything down into sub-tasks, so I'll just do the same ones as before, Create micro service, Add web page. (typing)

In JIRA, when you want to add multiple things, you notice this little box at the bottom, Create another. So if I wanted to add another sub-task, if I tick that and press Create, it would create it and now allow me to add another one. So what are we gonna do? How are we gonna do it? Next thing is to start the sprint, two week sprint. We know what our goal is. You can modify the goal, Start. I've started my sprint. I can still go back to my backlog and you can see that we've got the user story and we've got the sub-tasks inside the user story, there's Add to basket, and those it's sub-tasks.

Now it's not really for anybody to assign a task or a sub-task to a developer. So the development team will be picking these things up and they'll drag when a developer starts work, they'll drag the task that they gonna work on to in progress. You can have multiple of these columns if you want. And when all of the tasks are done, it will update the user story to done. So if you wanted an In Test here, you can do that. You can go to your Board and you can configure your Board.

So this is our SCRUM Board. It's kind of a picture paints a thousand words because we can see what's in flight, what's going on. Any questions on what you've seen there? Is that okay? So if you have these two things never happen I'm sure, but if you have got to add them in a sprint and stuff wasn't finished, is it the right thing to do? Just to move the stuff and start phasing to the next sprint? Well, not to the next sprint because what would happen is they'd go back onto the backlog. Okay. Yeah. And then they go back onto the backlog, you will have your review, you would have to tell them what you haven't delivered, they will then look at what you've got, and you will have to have your retrospective as well and learn the lessons of why you didn't deliver what you didn't deliver.

There may be issues around that, that go onto the backlog. And then you have to have your sprint planning. And what comes out to sprint planning is maybe it has re-prioritizations that may mean that the stakeholders, the product owner, has decided that well, what was on the last sprint, because priorities may have changed, that thing may not be on the next sprint. Okay.

So it isn't necessarily true that what didn't get delivered on the previous sprint will get delivered on the next sprint. It may be that if it was partially completed, it may be that they'll say, yeah, finish it. It may be that if it didn't even get started, it may be that they'll just say well, actually, you know, we need this now. So priorities can continually change. So you definitely wouldn't say that it goes to the next sprint. It goes back on the backlog. Okay.

On the flip side, if you somehow get through all the work in a sprint with five days to spare, what would you do then to fill up the time? Right. So there's a few things you do. First of all you would have good communication with your product owner, and you would be transparent with your product owner and say, "Look, we got through this much quicker." You could show your product down on a regular basis, what the product looks like.

You don't have to wait for the sprint review so you could say, "Hey, this is where we are now, is that acceptable to you?" "And if it is, then we've got more capacity than we thought we had." And then you could negotiate taking more on anything you could deliver. There's always technical debt as well that builds up within a SCRUM project. So the may well be things that you need to do to improve testing, to improve infrastructure.

There may be little extra things that you'd never get to, that you could then work on. But it's the good communication, the clear communication for the product owner. I'm you know, I was talking to the SCRUM master as well, and that's the key to it. So whatever is agreed by the SCRUM team is the thing that you do. But it's that transparency that is the key to it. Okay.

So it is acceptable to take more arm if you think you can deliver it. And that's fine. And it's just a change of scope. And in here that would be represented as a change of scope so you would be able to add to the sprint. You wouldn't end the sprint early. You would... You wouldn't end it early, you just add stuff to it. And it's just a change of scope. Yeah. We were just defining releases in JIRA.

I took that demo a little bit farther just to show you the whole process. What you're gonna do now is you're going to define your own version, why don't you have a go at doing that? Yes, so a story gets added to a version, and then we deliver one or more stories in our sprint. So a version is eventually delivered by you completing a number of sprints.

So what we've done is, when I say those are requirements, each one of these is a user story, and it's gonna be broken down into sub-tasks. And the users story is only completed when we've done all of the sub-tasks. The sub tasks being the things that the developers actually do. That's where they're writing code, that's where they're doing unit tests, that's where they're doing all of the bits that they need to do to complete a user story.

About the Author
Students1948
Labs19
Courses16
Learning paths6

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