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, right. So, if I was doing, lets say if I was doing the ticket bookings as a site included the page So the sizing clear to the pay. So the, is the booking tickets. So what we might do, the other customer, as a customer, I want to..., book, tickets, movie probably not the best, example. So I can and then what we would do, is , we would identify the scenario.
So scenario one, might be, we might say, book tickets, success. And then, given, a movie, selected , and sharing, shares. and they, number of seats has been selected, has a single, seats, between parties. When booking tickets So basically we're giving an example of what the acceptance criteria are. Maybe to give a bit more detail about what needs to be displayed but then we might give it another example.
Another seminar I have what happens if they haven't selected a movie or they haven't chosen tickets, what do we do? What do we say? What's the action? What are those examples? So we get very clear examples of how this would work. And so it's those examples that make it clear. And so in JIRA you might choose to capture this form of acceptance criteria in a description field, or a separate field. And like I said to you, you would, in that case, you would get your admin to add, a custom field into JIRA, on that box where, the administrators will be able to go in and add one of these custom fails. Cool. Okay. So that is capturing the requirements.
Three essential facts to summarize sprints. What would you say about sprint then? What is an important thing to know, about a sprint? is what's called definitive, or defined duration? Absolutely. So it's time box. Doesn't that a sprint is time boxed, we don't compromise on the time we don't say Oh, should we have another few days? Let's extend it by a week. We don't do that. The thing we're varying is what we decide we can deliver. Yeah. So we say, this is what, how much work we're going to take into the sprint backlog.
We've already agreed what our definition of done is, is going to be, so passes all tests, meets all the acceptance criteria. It has gone through the, the, the bail process. Okay. It's been demonstrated, and to the product owner already we've already shown these features. So it's sort of a certain set of death, a certain set of requirements. that we're saying is essential to meet before we can say, age requirement is done. And so we're going to always meet the same level of quality. So we don't compromise on quality. We always meet the same definition of done. And so the thing that varies is how much we take on in the first place. So it's iterative.
Why is it iterative? What were we saying earlier about scrum? So you can fail fast. So fail fast. So producing something that can be, we can get feedback on absolutely. releases and versions, if you come across this release in JIRA, I mean where, I know you will produce releases inversions. So we've got releases and versions and sprints and releases so that the two sorts of related ideas.
So I released a version, well what are we talking about would have released inversions. And how does sprints relate to releases? There's sort of two questions. What to release in a version? And second followup question would be, how does a release and aversion kind of relate to a sprint? is as a result of the sprint or release a version? So, I think, I mean, a complete could be completely wrong. with, to my mind, the end of a sprint, you have a release And then you might have already look which is which, which go to make a version.
Okay, So you might sort of say, we've worked on this for internally, we've had four, sprints, which has resulted in four releases. And now we're at a point where that makes version 1.1. So we're going to release version one of its kind, okay, although sorry, not to redeploy those who either, you're definitely, definitely very nearly there, you know, that that's very close, very close to the answer.
I mean, what we're producing at the end of a sprint sprint, if you think about the, the scrum guide it's talking about a potentially shippable product. So in other words that's a potentially releasable potentially shippable product but we don't necessarily do anything with it. It's something we might demo something we might get feedback on because we want to like with that fail fast but we might not necessarily do anything other than just get a bit of feedback. So a sprint definitely. Isn't something we have to, put life. we're not going to put it out.
Now we might let people see it. We might put people play with it, but that's for our benefit. And, so Sprint's releases. So the second part of your answer, definitely absolutely spot on that because what we tend to do and the way you would probably want to work this would be, to have, almost at the beginning of the project, to have, a release planning, meeting. I'm not saying it's sprint zero because there's no such thing as sprint zero. But what you would do, is you would identify, your releases. So that might be a release one, And that might be, release two.
Now your releases. This is where you've either decided that you remember user story mapping has decided that there's a whole bunch of things you want to be able to do. So we want to be able to do a whole load of things in here. So these are all the requirements that we want to deliver. These are all, I use the stories, now in order to get there we would have to, run, sprints of the same duration, that sprint one that sprint two, that sprint three, that sprint four.
So I released, you're building up to your release over a number of sprints and you're taking on , the user stories, as you going along obviously that doesn't match up, does it? So that's the relationship between, the release and the sprint. a version and a release are essentially the same thing. A version is something that you are putting in live. So the version is, is the version of the requirements that you're going to release.
So in JIRA the release , is actually a process that you can use to trigger certain things in other tools. So that's what, the relationship actually is. So scrum is characterized by units of work spreads that are short well-defined time boxed and the finish, is fixed. Process improvement is formalized in set meetings. We have our sprint review and we have the sprint retrospective.
Do you have, did you do sprint retrospectives? What you're doing is, is anyone do those you follow that pattern, sprint red froze, the review. Anyone remember what the review is for? displaying it, or demo and get to the, the stakeholders, to get their feedback. .That's that's right. So you're getting a review. You're getting you getting them to give you more information, more feedback, and where we're the guy if, what they think of the results of the sprint, while they think about potentially shippable product next steps, anything else that needs to be added into the backlog, new priorities? And then, that will help us with the next sprint.
The retro though is where we look at ourselves and we ask three questions. What are we going to stop doing? What are they going to start doing? What are we going to continue doing? It's not a witch hunt. It's not something that we start saying well, you didn't do this. You didn't do that. It's the way, what are we going to continue doing? What are we gonna stop doing? What are we going to start doing? What might we need to add in as a bunch of tasks into the backlog, that bits of work that we need to do in addition to what we're already doing, a lot of teams make it, a definite task, to identify a piece of work that will always come out of the sprint, retro to go into the backlog. And the daily scrum, you already told me as a daily meeting, that is just a review of what's happened so far in the last 24 hours.
So what have I done today? What am I doing tomorrow? What am I doing to move the sprint goal forward? So we've got our product backlog we've got our sprint planning. And so there's quite a nice diagram that describes the whole thing. And, and there's our potentially releasable increment. So it's all laid out nicely. The problem is if you compromise any of this stuff, it's a cause is an issue. They it's all absolutely , essential but getting into JIRA now, JIRA support scrum with the built in project type we've already seen. And it has a product backlog which we saw, and the product backlog is prioritized by position in the backlog.
It's a good idea to define a definition of done, which describes what are the things that need to happen when your acceptance criteria what has to happen to say that as your item, your issue is complete. So, except this criteria map also is passed. Is it accepted by the PO? Now this definition of dumb will change, and it usually changes as a result things that you find in your retrospective meeting.
So that's another good reason why you always want to have those meetings. A lot of teams include the definition of done as a checklist, as a custom field that they define as a checklist in the issues. So remember I said you can have custom fields in your issues. Well, a lot of people define that definition of done as little checklist that has to be ticked before an issue is marked as dumb.
A lot of teams also have a definition of ready, is an issue ready to be worked on. In other words, is it something we can take into a sprint? Good idea to have one of those as well. So in JIRA, we've got projects we've got versions, we've got components we've got apex, we've got stories and tasks and bugs. A story can belong to an Epic. Any of these can belong to ethics. And then all of these belong inside projects. And then these stories can be broken down into subtypes.
QA is the UK's biggest training provider of virtual and online classes in technology, project management and leadership.