In this article I will drill down in how we are handle the general and sprint backlogs.
We use the uber-backlog to stick everything we know we need to do at some point in the future. We use Epics for big or fuzzy thing like “Develop a New Website”, “Launch product XYZ” etc. but we also use the backlog for smaller things like “write script for new video blog”, “add picture to product XYB web page” etc.
Here is a screen shot of the backlog
On the left, we have the epics in order of priority for the current sprint with the marketing themes at the very top. This helps us break down the bigs thing too do into smaller stories in order of priority.
To the right, we have the stories committed in the sprint with the relative points. As a reminder and reference, each point is 1/2 day of work. Jira does a good job at allowing us to tag stories by the epics they belong to and visually see if we are allocating our effort according to the stated priorities.
Personally, I use the uber-backlog to stick things that come up during my 101s with my boss and other internal and external meetings so that I don’t forget about them.
Managing the backlog
- The Burn Down Chart (see below)
- The work view that allows each member of the team to focus on the stories at hand (see below)
- Ways to size stories, assign them to people, tag them by Epic so that we know which stories contribute to getting something big done over time
The general backlog is typically not well prioritized until I (the product owner) sit down with the scrum master the Friday before the beginning of a sprint and go through it and define the priorities for the next sprint by looking at:
- current sprint leftovers
- Not everything that is not getting done in the current sprint is automatically moved to the next. It is the whole notion of scrum. If it is good enough and you shipped it, leave it alone. Plus if you do this right, the stuff that does not get done was the less important anyway.
- existing backlog items
- Here is where I look at existing epics and stories in the backlog looking for those who should become a priority in the next sprint. If I feel like the epic is too big for a single sprint (e.g. create a new website), I break it down into something I think it is small enough that the team can get it done, e.g. design and create the product section of the new website). I also look at my own stories to see what’s important for me to get done in the next sprint. The scrum master also pings the team for things we should consider for the next sprint
- potential new things
- I sometimes create new epics and stories based on what I learned in the last sprint and what came up at the executive level or board meetings.
Once the priorities of the sprint are defined on Friday, the scrum master sends out an email to the scrum team to give them headsup on what’s coming in the next sprint so that they can
- start collecting their thoughts for the sprint planning meeting
- call out missing priorities
Backlog and Sprint Planning
During the 2-4 hour sprint planning, we take the top priorities which are typically expressed in terms of epics “Start new nurturing campaign”, “Launch product briefings” etc, and we break them down as a team until each of us knows what we need to do during the sprint to get each epic done. In other words, we don’t move to the next entry in the list of things we want to achieve in the sprint, until the one at hand is fully understood and stories have been entered in the sprint backlog of the team members who are contributing to it.
This is a time consuming exercise that achieve a number good things:
- Communication – everybody in the team reaches a pretty intimate understanding of we are signing up to do
- Transparency – we all know what we sign up to do and most importantly what we are singing up to do fo the team.
- Dependencies Identification – by breaking things down we identify dependencies within and out side the team so that we can be proactive about addressing and sequencing them
- Meeting Time Saving – by spending a lot of time having meaningful discussions about what we need to do in the sprint, we minimize the number of additional meetings we need to have in the coming 2 weeks
We stop going down the list when as a team we reach our sprint capacity (# of team members * 10 working days * 2 points per day). Each of us keeps some points reserved in the sprint backlog do do things that are not necessarily help the sprint (like a business trip ro customer visits).
At this point we start the sprint and people start working on their backlog.
Working the Backlog
Jira has a nice view for each member of the team to work on their backlog during the sprint. Here is an example from my backlog:
The left column has the list of committed stories still to be worked on, the middle contains the ones I am currently working on and the right most one the stories that have been completed.
It is very convenient to stay focused on the most important things in the sprint and see at a glance how well I am doing toward completing my commitments to the team.
Jira does a good job at tracking and displaying the burn-down chart which is proudly displayed on a big screen by the marketing bullpen. It typically looks like this:
I don’t stress about having the team close their stories as soon as they are done with them. I guess people get to update their closure in the second week.
The scrum master keep track of how accurate we are about sizing our efforts sprint over sprint. Some people confuse this with micro-management. It is not. It is about predictability and becoming better and better (realistic?) about what we can get doen in a 2 week sprint.
As you can see, we started by overcommitting pretty badly but we got better overtime and we are stabilizing around 75%-80% completion which is pretty good.
In a future post, I will cover in more details how we do the sprint review.
Let me know what you think and how you are using scrum to run things other that software development.