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 email@example.com.
- 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.
To backlog refinements involves updating the Product Backlog items to provide the information necessary to meet the definition of ready. So whatever that is, needs to have given when then definitions maybe. It needs to have the Connextra format, you might need to specify that those fields need to be filled in and need to be valid. So there might be a whole set of additional criteria, that is your definition of ready. And again, that document might something that changes or your definition might be something that changes as a result of your retrospective meetings.
We prioritize the backlog to reflect any changes that have occurred in our review, and it's reordered as necessary. It also needs to be estimated, and this is an ongoing process and time of... Part of the time allocated to a sprint and it's usually about 10% of the time is allocated to doing this kind of Backlog Refinement and work.
So, Sprint Planning you decide what the goal of the sprint is, determine which Product Backlog Items will be included in the sprint, break the PBIs down into sub tasks and you possibly might estimate the sub tasks. But this is really important, you ideally don't want your sub tasks to be bigger than a day's work. And the reason for that, if you think about it, is if you can make them so that they're no bigger than a day, they can be reflected on more accurately in the Daily Scrum. And if you've got problems, then those will become clear in the Daily Scrum.
So if your sub tasks are five days long, you might be four days in before it's clear what the prob... Of our problems. So, you should always be close to finishing your sub tasks whenever you're in a Daily Scrum. You either maybe just getting started or... But you're still quite close to finishing if they're only quite small sub tasks.
So estimation should involve the whole team, not set in stone, express uncertainty, make sure that everybody gets to express themselves, there shouldn't be one dominant person. And then there are lots of techniques planning poker where everybody shows these poker cards, that's only one technique, there are lots of other techniques that suits different teams depending on the dynamics of the team.
So, what you want to do is... As a self organized team is come up with the best strategy that encourages the widest set of opinions. People use lots of different estimation techniques, probably the most popular is Poker cards. But you could use simple numbers, you could use small, medium and large T-shirt sizes, Rock Paper Scissors. And Planning poker is often not always facilitated by the Scrum Master, and you can buy these poker cards, each team member will have a set of the poker cards, and you basically say, three, two, one, go and then everybody shows their card, whatever number it is, and the person with the highest and the person with the lowest basically says why they think it's bigger or it's small, and you come to a consensus. And then whatever the consensus is, that's what is added in.
Like we saw, in JIRA, go to one of your user stories, click on the three lines on the right hand side, and then you should see an estimate. You'll notice in JIRA, they only allow you to story point estimate stories, with everything else being accepted as the cost of doing the sprint. So if you put anything else into your sprint, you're basically saying we can deliver it in the sprint.
You can change JIRA so that you can estimate the other issue types as well but out of the box, you can only estimate stories. It's just a configuration, it's just a form of scrum that they implement out of the box. So you would talk to the JIRA admin about that, it's not difficult to do. And then stories and tasks can be broken down into sub tasks. Ideally, less than a day in length. You can time track them if you want to, you could enter an original estimate.
Again, time tracking is something you would switch on, but time tracking isn't necessarily an essential part of the sprint with it because the time box is really the thing that we're tracking, that's the timing bit. As long as we deliver within... As long as we deliver what we say we're gonna deliver within our time box, then how long you took on a sub task is not necessarily relevant, unless you want it to be relevant in which case you can configure it.
QA is the UK's biggest training provider of virtual and online classes in technology, project management and leadership.