Getting Started with Jira
The course is part of this learning path
This course provides an introduction to Jira and covers user stories, user story mapping, epics, acceptance criteria, and MoSCoW prioritization. By the end of the course, you're going to have a good understanding of the features available in Jira and how to use them to manage your workflows.
If you have any feedback relating to this course, feel free to contact us at firstname.lastname@example.org.
- Get a foundational understanding of Jira
- Learn about user stories and the related acceptance criteria, constraints, and business goals
- Learn what epics are and how stories roll up into them
- Understand user story mapping and MoSCow prioritization
This course is intended for anyone who wants to learn more about Jira and how it can be used as a tool to manage your workflows.
To get the most out of this course, you should have a basic understanding of Agile and Jira.
So, the user story defines some kind of requirement. And like we said, it's written from a user perspective, a user first approach. And we use these personas to discover stories. And a really important point here is to try to develop stories collaboratively. Now, if we were gonna do that who would you think would be good to involve in collaboratively working out a user story? A customer. A customer yeah. So somebody from it could be a customer, it could be a stakeholder, it could be a business analyst. It could maybe it could be somebody who knows the business, the domain, the area evolved, yeah. So somebody from that area, definitely who else? Product owner. Product owner yeah. Product owner potentially would be useful too. I would throw in developer, you'd want a developer involved as well. A developer would know what problems there might be, what technology problems, what technology restrictions there might be. And so you might be able to discuss what's possible and what's not possible. And, that could be a nice kind of addition to this collaboration. And there's one other role that we often involve in this kind of collaboration.
So we've got business, developer, The customer. (indistinct) Customer, yep, customer business yeah developer. End user. End user, we often use as the third role, we often fill the third role with somebody experienced in testing. So someone from business, someone from development a coder, a developer and a test role as well. And so those three together we often call them the three Amigos and well three Amigos. And those three roles together are often a really good collaboration to work through a user story. And when those user stories is developed the way it tends to work is they will discuss the personas discuss the goals of those personas and try and work collaboratively. And one of the best ways to do it is to work by example and to work through the examples of how a story should work and to identify examples of the story playing out.
We do something called example mapping. But very importantly, as I'm working on this, they may realize that the thing they think is a story is actually bigger than the story and is actually an epic because a story needs to be completable within a sprint. So what you may find happens is that those requirements that you're identifying which may start off towards the bottom of your backlog, they will have to be refined and refined and refined until they work their way up in your backlog and they get more and more detail added to them. And so that refinement process becomes important as well. But your user story will have a clear summary, a definition, an illustrative scenarios, as well acceptance criteria. And so when we create one in JIRA we've made sure that in JIRA, we give it a very clear summary.
So here we're creating a user story with a clear summary. Now that summary is what appears in the list in JIRA. So whenever you run a query, or this issue is displayed on the left, that's what's gonna display. So it needs to be short and to the point, you don't wanna have any funny codes in front of it. You don't wanna have any additional information other than what it is. And then in your description, this is where you can put the detail. And I don't know how well you can see that but in our detail we're describing other this is using the Connextra format.
As a bank customer I want to be able to, what is it they want to be able to do? I want to be able to withdraw cash from a cash machine. Why am I doing that? So that I can access funds within my account. So who am I? What am I trying to do? What's the benefit? I wanna be able to act, so I can get access to my cash.
So we can see that, we can see what's going on. What's that scenario therefore? To give the steps of what they're trying to achieve. Yeah so you can see that it's not enough just to say, as a bank customer I wanna be able to get cash from my bank account. Okay well thanks for that. It's not giving us enough it's clear, we always say that it's gonna be consistent but we need more. The scenario is giving us an example and it saying, given the accounts and credit and the card's valid and the dispenser contains cash.
When the customer requests cash then ensure the account is debited and ensure the cash is dispense and ensure the card is returned. So it's giving us an example of how it should work. Maybe not the best example in the world, but it's only there to illustrate that we can provide a scenario of what should happen when everything is fine. And then we can give another example of what should happen when everything isn't fine.
So when we're doing our analysis we can come up with a whole bunch of examples. Examples are much more illustrative than a whole set of rules. Everybody can understand that. Well, most people can understand, the business, developers. And the great thing is developers can take this and developers can turn this into unit tests. Is that okay? Any questions on that? For a second I feel a bit like a business logic, isn't it? There is no, so much like there is the business processes that you'd expect to be documented somewhere else so I would have thought. Yeah so, well, that's exactly right.
What we're doing is we're using a requirement but we're also using a, what's called a, we call this our ubiquitous language to describe how we want it to behave. So we're deliberately using a common language across the business, across the development, across testing, to describe exactly how the things should work. So everybody has the same definition and everybody understands the same definition. And that's why it's there, it's so the across the entire business across all of the different roles, it's absolutely clear what the process should be. And the alternative would be to have a lot of rules where it says, if this is the case, then do that.
When it's blank then we should show an error message, right. And when you do that, you'll have about a thousand different versions of creating a requirements. And this is aimed at creating consistency. Okay. And trust me, lots of organizations I've seen on the site and worked with on site who do this create a really are important level of consistency.
Now in JIRA, although you can put this in the description field. So let me show you that. So we could put all of this in the description field, in JIRA just like on the slide. JIRA is really flexible. So it's possible in JIRA to add additional fields. Now unless you've used JIRA a lot you won't now have to do this. But you can get your administrator, so there's the little cog wheel at the top right hand corner is where you can do administration and your all admins on the server. And as an administrator, and this isn't an admin course but it is possible for you to add custom fields.
Now I don't know how well you can see that, but there's a custom fields section here. And you can add your own custom fields. So what you could do if you wanted to, you could add your own text field and you could call it acceptance criteria. You could call it what you like. You could even have a requirement field that was just for user stories. And that might be another way of doing this.
So you could capture, you could have a general description but then you could have an additional field, one for your requirement and one for your acceptance criteria. And many organizations do that as well. So for user stories, they would have additional fields to capture this information. But from here it's entirely up to you how you would decide to do that.
When you're writing your user stories they should be investible. You'll see this on any course about user stories. So we've only got one chapter, but so the I, the N, the V, the E, the S the T. So independent, ideally from each other, and ideally schedule able in any order. So we don't want to, in our user stories we have to say we have to do this before we do that. It should be possible to order them any way that we want.
Negotiable, capturing the essence something that can evolve that kind of thing, obviously valuable. Estimable, can it be estimated? There needs to be enough information in your user story that will allow it to be estimated by the developers. If the developers can't estimate how long it's gonna take, then it's not possible to work on it. It's not possible to include it in a sprint.
A lot of teams and this is something that you can always use to improve what you're doing when you're doing scrum for example, is to have something called a definition of ready. And what most teams do is they will use about 10% of the sprint time to refine what's on the backlog with the product owner, to get it ready, to get the product backlog items ready, and to make sure that the product backlog items are estimable and have enough detail. And what that means the product owner has to go and get more detail, or whether some of the developers might need to add more detail. But estimable is something we need to know 'cause can we deliver it in a sprint is gonna be key.
Good stories are small, same as estimable really and they need to be testable. We need to have enough information to be able to prove that it works. And if you go back and you think about what we were talking about with our acceptance criteria and the way we define our user stories. We're ticking the number of those boxes with some of those techniques. And I can tell you those techniques do help hugely once you've got them consistent. So definitely that helps. I know it's a lot to ask to begin with but it's certainly worth thinking about that's all I ask.
So a bit of a repeat here but a user story will usually contain the definition, the acceptance criteria. And then we've got this Connextra format and then the state code X as a stakeholder, Y is the features, Z is the benefits. How does that sound everyone? Any questions on that? Does that sort makes sense? Yeah. Cool, okay. So customer withdraws cash and we've sort of seen this already in the slide earlier, but if you think about what you're doing here is you're ensuring that there is a user involved is it borrows a specific factor, you're identifying what it is that we're trying to achieve. And then why we're trying to achieve it.
QA is the UK's biggest training provider of virtual and online classes in technology, project management and leadership.