Estimates, Sub Tasks, and Logging Time
Jira and Scrum Methods
The course is part of this learning path
In this course, we take a look at how Jira can be used to introduce Scrum methods into your workflows. We begin by taking the looking at how Scrum processes can be facilitated through Jira.
We then look at a guided demo that covers release planning. You'll learn what to consider when planning a release and how Scrum methods can help you to plan the release through sprints. We also look at how all this can be achieved through the use of Jira. You'll also learn how to plan sprints.
We'll also look at estimates, sub-tasks within stories, and logging the time spent on tasks.
If you have any feedback relating to this course, please contact us at firstname.lastname@example.org.
- Learn how Jira can be used to implement Scrum processes
- Learn to plan releases and sprints
- Understand estimates, subtasks, and logging within Jira
Anyone looking to improve the way they use Jira to manage their workflows and projects, through the use of agile practices.
To get the most out of this course, you should have a basic understanding of agile and Jira.
Okay. It might be nice if you have a go, in your group, and pick a User Story. So one of you, share your screen. And or just in the chat window, share the description. And then in the chat window or just by talking, you could estimate what the estimates should be. And then you want to come up with estimates, find where that would need to be entered, and so use that to do your planning. So enter estimates agreed in Planning poker into Jira.
So literally, what we want to do is, we want to find where the estimate field is in our User Stories, and then also have a quick, we can't really do Planning poker particularly well using the tools that we've got. There are some adding tools that you can use. But just try doing it with chat, and just basically, if you co-ordinate it and say, 3-2-1, and then everyone send an estimate, a number, in the chat window. Could you explain what those mean again? Are they just an arbitrary scale? They are, yes. So they're really just talking about complexity. So one being, well, zero meaning no work at all is required. One meaning it's more complex, 100 meaning it's very complex. Infinity meaning we've got no way of knowing, and coffee meaning let's have a coffee break. We've been doing this for too long. So maybe everyone's going to show a coffee. (laughs) But we'll take a break in a minute, let's just do this.
So zero, half-one, so that's really all it is. One is much less complex than 100. And so it's literally just an arbitrary estimate, it's not time, it's literally just an estimate of complexity. But how would we translate that to something in time, if you needed to? Is it possible to have something to translate the values into? Some form of idea of time, so you can let senior management know, you know, how long is this going to take? The interesting thing is it's relevant to the team because what will happen over time is that the team will get to know, based on their own dynamics, that they can deliver a certain number of story points.
So based on their track record, they will know that as they get more consistent with their estimation, they will then realize that they can deliver 40 story points in a sprint. So if their estimation is consistent, and their development is consistent, they will then know how much to take on in every sprint. Okay. I guess that addresses the issue of variability, because the development teams will end up at different places. Exactly, that's right. Yeah.
So you'll find that one development team will say that they can deliver 40 story points, another one will say they can deliver 13, but they will usually both deliver similar amounts of work depending, well it depends on the capacity and it depends on how many of them there are and what their skill levels are, so there's a lot of stuff that goes into it. But yeah, so you can't really compare the velocity that a team has, which is the number of points they can deliver per sprint, You got different resources, you got different skill sets, you have different access to technical equipment. That's exactly right. But over time, the teams get really good at doing this, really consistent at doing this. So it's a relative estimate of what's possible for that team. So they will know what's simple and they will get to know what is very, very complex given enough information.
So what I'm going to do is just bring all of the things we've been doing together, and I'm just going to create a new project. If you've already got a project of your own, you could possibly use that. I'm just going to create a new scrum project. And just call it, My Website Project. And there it is. And like we said, to create backlog items, I can press the create button at the top of the Jira software bar. I can say my project is My Website Project. I can choose the kind of issue I want to produce.
So it's going to be a story. I can give my story a summary. So let's say... Create... Let's just call it Summary, Home Page. Okay, not the greatest user story in the world. Maybe create another issue like we said earlier, Pay with PayPal. And if you remember earlier on in the course, we also created epics and versions, epics being a grouping of user stories that are part of the same thing. So, payment processing might have pay with PayPal and pay with credit card.
Versions, which would be the delivery of a set of functionality that would be something that was releasable, which might include things, your stories, that were part of multiple epics. So it depends on how you're viewing the product. You might take an epic view or a version view, a release view. So there's my Home Page, there's my Pay with PayPal. And you might say, well actually, Home Page is most important, Pay with PayPal is most important, but if we thought it was the other way around, we would move Pay with PayPal further up.
So the ordering of the backlog is important. And then we might do an estimate, in terms of story points. So we said that was a three. And let's say that that is a 13. Right, I know it's not that complicated, from experience. But yeah. Break it down into sub-tasks. So that's as far as we've got with the exercise and the next step would now be to create a sprint. So you should have a create sprint button.
So create your sprint. You might want to set your sprint duration, in fact you will. We would have a sprint goal. So identify with the product owner, what the sprint goal is. A clearly defined sprint goal. We'll just leave that blank but you would want to have a clearly defined sprint goal. And then drag and drop those items that are going to be in your sprint. And then when you're ready, you can say start sprint.
Indicate the start date and you'll then be able to look at your scrum board which is the active sprint. So you can see there it's the one that's got three paneled icon. That's the active sprint. The backlog is the stack of Jenga blocks, the three panels is the sprint, the scrum board. And then you should be able to, if you added sub-tasks, that's when you should be able to drag them across.
Now the other thing the slide shows you, if you click on board and configure. So that was board, and configure, you can set a columns tab. The columns section on the left hand side. And this is where you can add statuses. So if you want to add a testing status, you could do that here. So you could add additional columns. In test, in analysis. We can also swimlanes.
At the moment, we're using user story swimlanes. And that's why we've got our Home Page User Story and our Pay with PayPal User Story as one swimlane, which are displaying the sub-tasks below. So a swimlane is almost like a section under which our sub-tasks are displayed. But you can change that if you want. And so, at the moment, base swimlanes on stories is set. But you can base swimlanes on epics or even projects.
So you could, if you wanted to, have a board that was displaying issues from multiple projects. Or even, based on who issues are assigned to. Or actually, even based on queries that you set up in Jira. So you can base them on your own queries. And that will control what the swimlane is called and then what's displayed in that section. So these boards can be much more flexible than you would at first think. And so our scrum board is our tracking tool as well as a way of keeping everybody apprised as to where things are in our project.
Chris, can I just ask a question, and I don't know if you're going to cover this before the end of the course. Sure, yeah! Are you going to show us how we assign time to work? So one of the biggest issues I have, is how long did everything take, how much did it cost? Is that covered here?
Right, so. What you can do is, out of the box it's not configured, so for example, for QA Cinemas, you add in the time tracking. So it's not in there by default. So this is something that you would configure. Now once it's there, if I go into QA Cinemas and I create an issue. And it's a story. I just had, that's the right thing. Yeah, so there it is. Now I've added it in, you can that when we create a story or even when we create sub-tasks, you can enter an original estimate and a remaining estimate. So you can do that and then when a task is entered you can, on any issue, you can then log the amount of time remaining.
Now it starts getting more complex because in a transition from one state to another, so for example, when you move from say, in progress to done. So if we were in a, let's go to the scrum board for example. So if I go from here to here, you can actually configure it so it pops up a screen. So when that happens we can also make it pop up a screen that makes the user enter time tracking information. So before it goes to done, you can pop up a screen that makes them enter the amount of time spent.
So you can do it, you can actually make it part of your workflow. But that's something you would get an admin to set up. So time tracking is possible, but you can also make time tracking part of your workflow process, too. Okay, that was great. Thank you. Okay, no problem.
QA is the UK's biggest training provider of virtual and online classes in technology, project management and leadership.