Sprint planning done right
Planning block. Session 2
JIRA exercise
Overview
Apart from the process, the sprint planning meeting is done so team members can align themselves around
- WHY is this sprint valuable (motivation)
- WHAT can be done in this sprint (what items from the backlog)
- HOW will the work get done (by developers)
Align means they ask questions if there are any. Developers, QA etc think from their perspective and (1) ask clarifying questions to provide accurate time estimates.
You may appreciate this may be daunting on a regular basis. Best approach here is “The devil is in the details” and “Think deeply and move quickly”. If you want me to elaborate on these, please leave a comment below.
Align also means (2) capability check with Engineering team (past performance, current velocity) and (3) availability of resources, tools and infrastructure from Engineering perspective.
Prerequisite
- Adequately refined (sprint-ready) product backlog items
- prioritised
- have sufficient level of details (well defined, right size)
2. Planned team capacity
The process
Sprint planning is an important part of the agile development process, and JIRA is a popular tool that can help teams plan and organize their work. To do sprint planning in JIRA, follow these steps:
- Create a new project in JIRA, or choose an existing project to work on.
2. Create a new sprint by going to the “Product backlog” view on JIRA and clicking on the “Create Sprint” button.
3. Add the user stories or tasks that you want to include in the sprint to the backlog. This can be done by dragging and dropping items from the backlog onto the sprint.
Some of the details to include. Click on edits or add dates, then
- set the duration (2 weeks). 1 week if you have volatile requriements.
- name it with the focus, so it’s easy to remember in the future
- set the sprint goal (WHY part).
4. The next is to establish the teams capacity. Two ways to go about it
- velocity and story points
- time-based approach (estimate items in hours)
4.1. Velocity and story points
Go to All reports -> Velocity chart
Green bar is actual completed velocity and grey is what was committed. To calculate it’s enough to use last 3 sprints
(21+18+26 ) / 3 = 21.7 -velocity
This determines what can be done in upcoming sprint. Don’t exceed otherwise stakeholders will be upset. Instead leave it for buffer for
- pay down tech debt
- work on process improvements (test or deployment automation)
- spend time refining product
- have an “innovation day” like Atlassian
What may make the calculation to not be reliable, accurate?
- non-consistent sprint length
- team number is not stable
- other irregularities such as holiday, annual leaves
Pros of team velocity method:
1. Quicker
2. Greater comfort within teamCons:
1. Requires a few sprints to estimate
2. Accurate but not precise
3. Harder to understand
4.2. Time-based approach
Team have to come prepared with how much time they have to dedicate for the upcoming sprint. Otherwise what you will see is the team will be failing to complete the sprint planning: items will be half done, incomplete or moved to the next sprint. The long-term downside is the team will be demoralised.
Capacity planning can be done using this spreadsheet. Share the file ahead of the Sprint planning meeting and ask the team to update their times.
5. Once the sprint is created, invite your team members to join the sprint and assign tasks to them.
Start of the session with the Product owner
- opportunity to ask PO clarifying questions
- clarify priorities
5.1. Creating sub-tasks (can be without Product Owner)
Under backlog item / story there is a tick icon to click.
Process of adding sub-tasks will require you
- creating the granular item (each team member can add their own associated task)
- assigning it to a team member (members self-manage it)
- adding indication of how long the sub-task will take (click on the text/title scroll down and add Original estimate in hours)
Considerations for sub-tasks:
- size should be between 1h-8h (day long). Not longer than a day
- get the team to create based on definition of done criteria
Example DoD
- all functional test cases pass
- peer reviewed and standards met
- support documentation written and reviewed
- meets acceptance criteria
- reviewed and accepted by product owner
Determining team capacity left go to Workload pie chart. Go to Dashboard → All dashboards -> Give it a name → Add a new gadget (chose from the list on the right by scrolling down )
- In the pop up it will ask to add a filter. Go to filters -> add this in jql field
Project = “[YOUR PROJECT NAME HERE]” AND sprint in futureSprints()
- Statistic type → Assignee and click Save
What you will see is the amount of hours allocated which you will need to check against the capacity in the spreadsheet.
Pros of the time-based approach
1. Greater precision
2. More likely to complete the sprint plan
3. Improve estimation by tracking original estimate vs time spent (this will help in Retrospective and future estimates)Cons:
1. Takes more time to do
2. Might be perceived as micro-managing
3. Discomfort with time estimation. How to tackle this: ensure backlog items are “sprint ready”, inform the team this is for planning not punishment. Worst case: erase the times after Sprint planning is done
6. Going into each story details to consider
- technical implementation (who is doing what)
- dependencies (integration with 3rd party API, need for info from subject matter experts)
- risks (someone is away, unknown technology)
7. In further progress, team members can update the status of their tasks in JIRA, and the sprint burndown chart will show the progress towards completing the sprint.
Before you hit the Start Sprint button
- ask the team if they feel it’s realistic
- consider the sequencing
By following these steps, you can use JIRA to effectively plan and manage your sprints, and ensure that your team is on track to deliver high-quality work.
Credit: Axisagile, OpenAI
If you found this information useful, please follow me to stay up to date. If you’d like to buy me a cup of coffee, you can do so through Ko-fi at ko-fi.com/ayuby
