Posts Tagged ‘sprint backlog’

The Ideal Agile Workspace

Thursday, March 5th, 2009

As you may now, I am working on a new book, which will be called Succeeding with Agile. I recently finished writing a chapter for it on the impact of the human resources and facilities groups on an organization that is transitioning to agile. While writing that chapter, I put together a list of all the things that I think should be visible within the ideal agile workspace:

  • Big Visible Charts. Alistair Cockburn coined the term “Big Visible Charts” to describe the charts that agile teams like to hang on their walls. One of the most common of these is the sprint burndown chart, showing the number of hours remaining as of each day of the current sprint. Charts like these provide a strong visual reminder of the current state of the project. What is shown on these charts will get the attention of team members so display charts showing the most important information for that sprint. Ron Jeffries suggests considering big visible charts showing the number of passing customer acceptance tests, the pass/fail status of tests by day, sprint and release burndown charts, number of new stories introduced to the product backlog per sprint, and more.
  • Additional feedback devices. In addition to big, visible charts, it is common for an agile team to use additional visual feedback devices in their workspace. One of the most common is a lava lamp that is turned on whenever the automated build is broken. I’ve also worked with teams that use flashing red traffic lights to indicate exceptional conditions such as an issue on a production server. Also popular are ambient orbs and Nabaztag rabbits, which are wireless programmable devices that can also be configured to change colors, speak messages, or wiggle their ears as a team desires. Devices like these make a workspace more dynamic, unobtrusively bringing into it information the team may find helpful.
  • Everyone on your team. Each person on the team should ideally be able to see each other person on the team. This absolutely includes the ScrumMaster and ideally includes the product owner. I do understand, however, that product owners often have responsibilities to other groups outside the development team and so may sit near them instead. Still, in an ideal world the product owner would be visible to everyone in the team workspace.
  • The sprint backlog. One of the best ways to ensure that everything necessary is completed in the sprint is to make the sprint backlog visible. The best way to do that is by displaying the sprint backlog on a wall, ideally in the form of a task board A task board is usually oriented in rows and columns with each row containing a particular user story and one index card or sticky note for each task involved in that story. Task cards are organized in columns, minimally including “To Do” “In Process,” and “Done.” In this way, team members are able to see work progressing across the task board during the sprint and all work to be done is visible at all times.
  • The product backlog. One problem with running an endless series of sprints is that each can feel disconnected or isolated from the whole of a planned released or related set of new capabilities. A good way to reduce the impact of this problem is by displaying the product backlog somewhere clearly visible. This can be as simple as keeping the shoebox full of user stories written on index cards on a table in the middle of the team’s space. Even better, tack the index cards with those upcoming user stories on a wall where all can see them. This allows team members to see how the user stories they are working on in the current sprint relate to others that are coming soon.
  • At least one big white board. Every team needs at least one big whiteboard. Locating this in the team’s common workspace encourages spontaneous meetings. One developer may start using the board to think through a problem; others may notice and offer to help.
  • Someplace quiet and private. As important as open communication is, there are times when someone needs some peace and quiet. Sometimes this is for something as simple as a private phone call. Other times it can be to think through a particularly challenging problem without being interrupted.
  • Food and drink. It’s always a good idea to have food and drink available. These don’t need to be fancy, and they don’t even need to be provided by the organization. I’ve worked with plenty of teams that buy a small under-desk refrigerator and share the expense of buying water bottles or soda for it. Other teams buy a coffee machine, depending on team preferences. Some teams rotate bringing in snacks, both healthful and not.
  • A window. Windows are often a scarce commodity and are doled out to an organization’s favored employees. One of the nice things about an open workspace is that windows are shared. Even if the view is only of our parking lot and can only be seen across three messy desks, at least I can see the window and some natural light.

It’s unlikely that every one of these will be visible from your workspace, but the more of them visible, the better. Let me know what else you think should be visible from within the ideal agile workspace.

Posted in Sprinting | 28 Comments »

Why There Should Not Be a “Release Backlog”

Sunday, February 8th, 2009

I haven’t heard the term “release backlog” in many months, but it’s come up in three conversations over the past week. So, I want to share my thoughts on whether a team should have a Release Backlog in addition to the conventional Product and Sprint (or Iteration) Backlogs.

First, let’s clarify what people mean when they refer to a “release backlog.” A release backlog is a subset of the product backlog that is planned to be delivered in the coming release, typically a three- to six-month horizon. A release backlog would presumably contain the same type of items as on a product backlog. My preference for this, of course, would be user stories. So, at the start of some release planning horizon, a product owner with help from the team and other stakeholders would example the product backlog, select some amount of high priority work and move those items to the release backlog. Later, in sprint (iteration) planning, the team would examine the release product and select some amount of work to do. (Notice how this already goes against existing agile literature that says the team selects top priority items for the sprint from the product backlog?)

I am opposed to the use of a release backlog for a couple of reasons:

First, in all projects that are not being done as fixed-scope contracts (and, arguably, even then) we don’t know exactly what user stories or features will be delivered in a release. To say that there is a release backlog may not imply a guarantee that all features on it are delivered. However, it does create additional work as items are moved off back and forth between the product and release backlogs. This will happen as the team’s velocity changes (even by small amounts) from sprint to sprint. If the release backlog is to show what a team will deliver in a release, it should contain an amount of work equal to the number of story points (or ideal days) times the number of remaining sprints. If you have an average velocity of 20 and 6 sprints left, the release backlog should contain 120 points worth of work. Suppose the team finishes 24 points of work in a sprint. The backlog is now down to 96 points (120-24) but should contain 100 (5 sprints left x an average velocity of 20). Things get even more difficult if that good velocity of 24 increases the team’s average velocity to 21. In that case the release backlog should contain 5×21=105 points of work; we need to move 9 points of work from the product backlog to the sprint backlog. If there’s a release backlog, this moving of items back and forth from product backlog to release backlog will happen every sprint.

Second, introducing a release backlog creates additional confusion. We’ve already overloaded the word “backlog” with “product backlog” and “sprint backlog.” Why confuse things further with a third type of backlog unless there is an immensely compelling reason to do so?

Third, introducing the concept of a Release Backlog actually makes it harder for product owners to do one of the most important things they should be doing–looking at the features or user stories that just miss the cut of being in a release. When I look at a product backlog and count down the number of story points that I anticipate will be in the release, the most interesting thing to me is not necessarily the set of user stories that will make it into the release. I’m often just as interested in the next few user stories below that cut-off point. That is, I want to know what user stories won’t quite make it into the release. After all, we say that one of the benefits of agile (on some, not all, projects) is the ability to decide later if we should release a few sprints early (if a lot has been done), on the planned date, or perhaps a sprint or two late if we want to add more functionality before a release. This is made more difficult with a Release Backlog because a product owner now needs to examine both a Product Backlog and a Release Backlog to make these decisions.

So, what do I propose instead?

I advocate that all teams track their velocities. This leads to a graph like this:

Velocity as graphed over the last nine sprints.

This graph shows a team calculating three average velocities:

  1. Long term average, defined as the mean of the last eight sprints
  2. Worst case average, defined as the mean of the worst three chosen among the last eight sprints
  3. Best case average, defined as the mean of the best three chosen among the last eight sprints

You can choose your own ways of calculating long-term, best-case, and worst-case average velocities. These are just the ones I like. We use these average velocities as shown in this figure:

Using velocity to predict how much will be done by a given date.

In this figure, the product backlog is shown on the left as a stack of index cards. We use the three average velocities multiplied by the number of remaining sprints to draw arrows pointing into the product backlog. The range created by these arrows indicates the likely amount of work finished by the planned date. Our release plan is the work defined by the arrows. Rather than a Release Backlog as a new work product or artifact, my equivalent of a release backlog is the product backlog and these arrows pointing into it.

As you can imagine, predicting velocity as a range is much more likely to be accurate than using a single point estimate (“Our velocity is 31.”) as has been implied by everyone I’ve heard talk about a Release Backlog. Additionally, looking at figures like these should make it apparent that the amount of work expected to be delivered in a release will change from sprint to sprint. Pointing arrows into a product backlog is much easier and more helpful than creating a new work product, the Release Backlog.

Posted in Agile Planning, Sprint Artifacts | 48 Comments »

Clarifying the Purpose of Iteration Planning

Tuesday, November 25th, 2008

I was recently asked whether it would be OK for a team to complete their iteration planning without going to the point of estimating tasks in hours. To answer this, let’s consider what the purpose of iteration planning is.

In my view, the purpose of the iteration planning is for the team to arrive at a commitment to some set of functionality that they feel reasonably confident they can complete in the coming iteration. The purpose is not to identify tasks. The purpose is not to estimate the number of hours for each of those tasks. The purpose is to figure out how many and which product backlog items they can commit to delivering in the coming iteration.

If a team can do this without discussing tasks and hours, so be it. If a team can walk into the iteration planning meeting and one team member announces, “Sssh, I’ve receiving divine inspiration……… We can do the first three items plus the sixth on the product backlog,” I would call the meeting over and we’d have our commitment. I’d be impressed and I’d be skeptical, but we’d be done with the meeting.

Since I haven’t seen a team do this yet, I strongly recommend that an iteration planning meeting involve identifying tasks, estimating the effort of each, and then using that information to arrive at a set of product backlog items the team can commit to. I think this is the best way for a team to arrive at that reasonable commitment that I believe is the purpose of this meeting. Is it the only way? No. I’ve also worked with teams who decide that they will split work up such that all tasks are “about half a day”. They then can skip explicitly estimating the hours for each task because, in a way they’ve already done it.

But, until I learn how to receive divine inspiration at the start of my iteration planning meetings, I’m sticking with identifying tasks as hours as a good way to figure out how much to commit to.

Posted in Agile Planning, Sprint Meetings | 25 Comments »

Should a Team Swarm on to One Backlog Item at a Time?

Monday, October 20th, 2008

This week I want to address the question of whether a team should work on one product backlog item at a time or whether it’s OK to work on multiple items.

In general, a team should feel comfortable working on multiple product backlog items at the same time during an iteration. A typical seven person team will plan between five and ten items into an iteration. They’ll usually be closer to the low end of that range with a one- or two-week iteration and closer to the high end with a four-week iteration. Perhaps surprisingly, though, iteration length has less influence on the number of product backlog items selected than you might think. It seems that teams with longer sprints simply have larger product backlog items.

A seven-person team will rarely be at its most efficient when all team members swarm onto a single product backlog item. There’s too much opportunity for them to get in each other’s way for this to be a good long-term strategy. However, an entire team swarming onto a single product backlog item can be a very effective learning technique and one that I often encourage. If you are part of a team that hasn’t yet learned how all disciplines can work well together, limiting the entire team to one product backlog item in progress at a time is something you might want to try. This forces people to quickly learn ways to work in small batches so that work can, for example, be transferred from programming to testing in multiple tiny increments.

Similarly, if you are on a team where each developer grabs a product backlog item and works independently on it throughout an iteration, a rule of “only one item in progress at a time” is a good way to experience the benefits of working in smaller batches.

So, while I think swarming in this way is an excellent technique to use sometimes, I don’t think it should be the default way of working for very many teams. Some may benefit from it over the long term, but most will find that it introduces too many opportunities to be in someone else’s way as they try to make progress. I consider it equivalent to a drill that a team may do to improve a skill–good to use for practice but not the way to do something forever.

Posted in Sprinting | 15 Comments »