Sprint Planning and Estimation
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.
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.