Product backlog items can be ideally written to be independent. It is the hallmark of a good team that its members can implement product backlog items in any order. However, it would be nearly impossible to remove all dependencies between product backlog items and so our goal becomes minimizing important dependencies rather than eliminating them altogether.

But any dependencies that remain can raise questions about how to estimate the individual product backlog items. One common question is what to do with work that could be performed as part of either of two backlog items but that only needs to be done once. As an example, consider these two product backlog items, which are written as user stories:

• As a user, I can add an invoice to the system so that it gets paid.
• As a user, I can delete an invoice.

These two user stories share some work. Supposing this is a very simple system, whichever one of these stories is done first will also involve the team much of the database design for invoices. Some database design work (a cascading delete between Invoice and Line_Items, for example) will be done only when a specific one of the stories is developed. But, some work (deciding that a table called Invoice exists at all, perhaps) will be done as part of whichever story is implemented first. Assuming that this work is non-trivial, the estimates given to these stories will be influenced by which will be implemented first.

In deciding how to estimate these and how to handle the common work between them, I suggest there are two guiding principles we can rely on:

• We should assume work will be done in its natural order.
• The sum of all estimates on the product backlog should represent the total size of the project (as understood at that time, of course).

Let’s see how these two principles lead to the answer about how to estimate our two user stories about adding and deleting invoices. Although a good agile team should be able to implement these stories in either order, it is most likely that the product owner will ask the team to add invoices first. After all, you can’t delete an invoice until it has been added. This is what I mean by the natural order.

Although it is natural to add invoices to a database before deleting them, it is not hard to imagine a need to do these in the opposite order. Suppose our team is writing a new system to interface with an existing invoice database. That existing system is full of old invoices from the 1940s and the first thing the product owner wants is the ability to delete old invoices.

When a product wants stories done in the natural order or when it seems likely the product owner will want them done in that order, my advice is that the team should estimate with that assumption in mind and not bother noting it on the story cards. Documenting all logical assumptions about the natural order gets tedious. To document all such assumptions, our add an invoice story would also need to be documented with “assumes login story is done first,” and so on.

But when a team knows or suspects they will be asked to work out of the natural order, they should document the assumption. If the team assumes that adding an invoice will be quicker to implement because deleting is already done, they should add appropriate notes to these story cards.

Teams are, of course, sometimes wrong in their assumptions or are surprised by product owners who change their minds. These situations are resolved by simple discussion along the lines of saying “We assumed you’d want these stories in a different order. So, a few points [or ideal days] of work move off this story and onto that story.”

It is even possible that working outside the natural order can sometimes increase the total size of the work. For example, to do the delete invoices user story before the add invoices story, our team might need to write a short script to preload the database with dummy data just so we can be sure delete is working. Usually when this happens the change in project size is very small and washes out in the noise of other estimating and planning errors. (In other words, it’s rarely worse than someone being out sick for a day.)

Why not get around this problem of potentially moving points from one story to another by assuming that each story is done first, which would be a worst case for its estimate? This is where our second principle comes in: The sum of the estimates should add up to the total size of work being considered. If the total work is 8 and that’s what we’d put on a single add+delete user story then our two user stories need a total of 8. To put a higher number on them overstates the size of the project. This would lead to incorrect projections of the project completion date based on velocity.

A client asked me last week “When will my team be done with this project?” This is probably the bazillionth time I’ve been asked that question in one way or another. I have never once been asked, “How hard will my team have to think to develop this project?” Clients, bosses, customers, and stakeholders care about how long a project will take. They don’t care about how hard we have to think to deliver the project, except to the extent that the need to think hard implies schedule or cost risk.

I mention this because I find too many teams who think that story points should be based on the complexity of the user story or feature rather than the effort to develop it. Such teams often re-label “story points” as “complexity points.” I guess that sounds better. More sophisticated, perhaps. But it’s wrong. Story points are not about the complexity of developing a feature; they are about the effort required to develop a feature.

In a class a few years back, I was given a wonderful example of this. Suppose a team consists of a little kid and a brain surgeon. Their product backlog includes two items: lick 1,000 stamps and perform a simple brain surgery–snip and done. These items are chosen to presumably take the same amount of time. If you disagree, simply adjust the number of stamps in the example. Despite their vastly different complexities, the two items should be given the same number of story points–each is expected to take the same amount of time.

This example also points out another aspect of agile estimating, which is that we assume that in general the right person for the job will do the work.We do not assume the little kid will finish school, go to med school, do a seven-year residency and only then begin the brain surgery while we have a skilled surgeon sitting in a cubicle licking stamps. Of course reality intrudes and occasionally the “wrong” person for a job does the job, but that will rarely be as dramatic as in this example.

So, story points are about the effort involved. Feel free to adjust your estiamte of effort based on things like risk and uncertainty, but point-based estimating is about the time the work will take. It’s what our clients, bosses, customers, and stakeholders care about.

Laurie Williams, a professor at North Carolina State University, recently conducted a survey to find out which principles and practices are used by agile teams. If you read my monthly newsletter, you probably saw the announcement asking for people to participate. She had over 300 responses and released the results today. Among the findings were that these are the most important principles based on the number of respondents rating their importance as “Very High”:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Working software is the primary measure of progress.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
5. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The survey also asked which practices where essential for a team to be considered agile. The top five were:

1. Short iterations (30 days or less)
2. Continuous integration
3. “Done” criteria
4. Automated tests are run with each build
5. Automated unit testing

She is doing a follow-up survey about the agile principles. You can take that survey online. I will share the results here when they are available

You may have noticed we’ve been adding tools to the Mountain Goat Software website occasionally. We have a tool for calculating a confidence interval around your velocity data as well as various tools for prioritizing user stories or projects against one another. I’ve got a new tool to announce today—Project Success Sliders.

Project Success Sliders were initially created and devised by Rob Thomsett in his book, Radical Project Management. Sliders are a way for a product owner (or collectively all key stakeholders) to convey expectations to the team. By default there are six sliders, each of which reflects some dimension by which project success can be determined—for example, delivery of all planned features, quality, meeting an agreed upon schedule. This can be seen in this figure:

Each slider starts at a value of three along a continuum from one to five. The product owner or key stakeholders then moves sliders up or down to reflect the appropriate mix of factors in determining the success of the project. Stakeholders are prevented from simply moving all sliders to five by a rule that that every movement up must be offset by a corresponding move down.

If sliders are out of balance (e.g., too many have been moved to higher numbers), the green checkmark in the upper right is replaced by a red circle and number showing how far out of balance the sliders are as you can see in this figure:

Sliders are brought back into balance when the product owner or stakeholders made additional adjustments to the sliders as shown in this example:

Project success sliders can be a useful way to create an appropriate dialogue between stakeholders and team members about how success will be defined on the project.

Be sure to check out our Project Success Sliders tool and let me know what you think

Risk management is a central part of traditional project management and is included as one of the knowledge areas in the Project Management Institute’s (PMI) body of knowledge. In many of my classes, participants ask how Scrum and agile address risk management. Some are concerned that agile or Scrum ignore risk management completely. Let’s see why this is the case.

First, a great deal of explicit risk management becomes unnecessary when a project uses an agile approach. The short iterations, single-minded focus on working software, heavy emphasis on automated tests, and frequent customer deliveries help teams avoid the biggest risk most projects face—that of eventually delivering nothing. So, it is not surprising that many agile projects forgo any form of explicit risk management. To put it in risk management terms, for these projects the likely savings from explicitly managing risks is outweighed by the cost of explicitly managing risk.

So while some short and inherently low-risk projects can be safely undertaken without any formal risk management, other projects are likely to benefit from explicitly managing risk. To see how we can do this, I want to describe a technique originally introduced by John Brothers in The Agile Times in 2004: the risk burndown chart.

Before we create a risk burndown chart we first need something akin to the typical risk census, which is merely a list of a project’s top risks along with the probability of the risk occurring and the size of the loss that would occur if it did. An example is shown in the following table, which I’ve simplified by eliminating a few columns that are not essential to this post:

Our simple risk census here describes each risk, provides an estimate of how likely the risk is to occur, the impact to the schedule if the risk did occur, and then the expected exposure to the risk which is the probability multiplied by the size of the loss. I recommend creating a risk census during the first sprint planning meeting and then updating it quickly during subsequent planning meetings as new risks are identified or as the probabilities or sizes of known risks change.

The risk burndown chart is then created by plotting the sum of the risk exposure values from the census. My recommendation is to sum only the top ten risks even if the team has identified more. Do this even if the top ten change over the course of the project. A sample risk burndown chart will look like this:

As with a regular release burndown chart, we should see a linear drop in risk over the course of the project, as shown in the red line of this next risk burndown chart.

When risk is not coming down at the appropriate rate, the team may want to budget some time in the next sprint to work directly on risk mitigation.

So as we can see from these examples, it is possible to take risk management seriously on agile projects that need to explicitly do so. And the risk burndown chart provides a convenient way of visualizing changes in risk.

Stealing a page from the software development industry, the World Champion New York Yankees have decided to send of their players offshore. Although New York will remain team headquarters, some players will now play their parts of games in the popular offshoring centers of India, Ukraine, and Brazil. The move is expected to save the Yankees $10 million in each of the first three years with no decrease in the number of wins each year.

All games in the 2010 season are scheduled to start at the customary New York start times. Players working in offshore locations have agreed to shift their working hours to accommodate US start times. Alex Rodriguez who will be playing in Kiev commented that “I don’t expect any degradation in performance from starting games at 2 A.M. And if my performance does start to suffer, I suppose there are drugs I can take to keep me awake and performing at my best.”

Shortstop Derek Jeter notes the importance of recent technological advances in making all of this possible: “Just a few years ago, this would have been impossible. But technology has advanced to where playing a game in at the same time on eight or nine continents is possible. Using the Wii, a pitcher in Boston can pitch to me in Bangalore and I can hit it out of the ballpark in Kiev.”

Manager Joe Girardi says he is looking forward to utilizing a “follow-the-sun” approach to games. The days of occasional double-header or extra-innings games going late into the night when played solely in New York are a think of the past. Girardi says that, “We can go to bed at a reasonable hour here in New York after, say, the fifth inning and players in India will finish the game for us,” Girardi says.