Change Strategies by Henrik Kniberg. Mindmap created in Mindmeister by Max Wenzin. View full map in Mindmeister.

Change Strategies

• Ask for foregiveness rather than permission
• Use metrics
• Reversible “experiments”
• Set an example
• Talk to everyone at once & Capture the intent
• Visualize the current situation
• Compare options
• Make a business case for your change

When to use a web-based tool instead of a wall board (whiteboard)

• When you have distributed teams
• When you want to work on your tasks from multiple locations
• When you need to share information with outside stakeholders (like customers)

If you have a simpler scenario, try using the simplest tool possible for your task tracking, like a whiteboard.

Screenshot of Jira

Before Sprint Planning

It’s the job of the Product Owner to keep the Product Backlog groomed & ordered. The items on top of the backlog should be well enough specified so that they can be moved into a Sprint Backlog. This work is ongoing and often means talking to stakeholders a lot.

Before Sprint Planning I prepare one Jira “bucket” per team. Usually I use one Jira “Version” for each Sprint and add a custom field (“Sprint Team”) to track which team a specific issue belongs to.

I fill the buckets with issues I find suitable for each team until there’s more than enough issues for each team. How do I know how much is enough? Past performance. Do I have estimates on all issues? No, usually not. Perhaps on some.

This results in a preliminary Sprint Backlog. This is not the final Sprint Backlog, but only a suggestion.

I usually juggle a bit with the ordering (prioritization) to make sure the most important issues are on top. Also, if there are any bigger or riskier issues, I move them up the list so they are handled early in the Sprint.

A few days before the Sprint Planning meeting I send out links to the preliminary backlog to the teams. At this time, the suggestion for next iteration should be pretty stable, but changes can still occur.

This enables the team to:

1. Review the issues in advance (makes for a quicker and less painful Sprint Planning meeting)
2. Give me feedback on poor priotization, poor team choice etc

Managing left-overs

During Sprint Planning meeting

It is the job of the Scrum Master to send invites to the Sprint Planning meeting. The Product Owner is just there to clarify the backlog and answer questions. I try to take a backseat position here if possible and let the team drive the planning as much as possible.

Since the teams are often distributed in different parts of the world we usually use Skype for voice and some screen sharing software to display Jira.

Quick overview of Sprint Planning process using Jira:

• Display list of issues (preliminary Sprint Backlog) in Jira and talk about the overall goal of the Sprint
• For each issue in the list:
• Team reads the issue
• Team discusses the issue and asks the PO when in need of clarification
• Team estimates the issue using Planning Poker or similar technique. Estimation is entered as “Time Remaining” in Jira. (or if estimation is done in “Story Points”, in some other suitable Jira field)
• When the team feels that they have enough issues to fill a Sprint, the process ends. This is usually done by summing up the “time remaining” on the issues in the Jira “bucket” and when that sum reaches what the team usually manages (their velocity), then they know they have enough. Please note that summing up “Original Estimate” is not a good idea if you have work-in-progress left-overs from last Sprint.

After Sprint Planning

Directly after Sprint Planning I kick all issues that didn’t make the cut to the next version so that the teams bucket only contain what they have committed to for the new Sprint. Then I send a Jira link to the stakeholders so they can see exactly what the new Sprint Backlog contains. I may only send them a list of the issues that didn’t make the cut if I know they were expecting some specific issues.

I usually have some Jira filters for each Sprint to make it simple for the teams to know what issues to work on. I update these for the new Sprint.

Here are some example filter names:

• Current Sprint – TODO – Team A
• Current Sprint – TODO – Team B
• Current Sprint – TODO – Team C
• Current Sprint – TO TEST – Team A
• Current Sprint – TO TEST – Team B
• Current Sprint – TO TEST – Team C

You can probably figure out what these filters show…

Closing thoughts and further reading

Admin Ninja Black Belt, courtesy of Atlassian

I hope this guide gives you some idea how you can make it work. If you wish to read more about Jira in general, visit Atlassians Jira section. If you are unsure of the Scrum terminology used here, or just want to know more about Scrum, check out Scrum Alliance. If you want help implementing Jira at your workplace, keep me in mind. I am a Jira Admin Ninja Black Belt.