My three books on agile made this list of “The Top 100 Agile Books” by Jurgen Appelo. He used an objective method of ranking books based on Amazon.com and GoodRead.com quality ratings and popularity. His blog explains the approach. Uncle Bob Martin and I were each fortunate enough to have two books in the top ten.

Just about all the books on the list are worth reading so pick up a few of them if you’re looking for something good to read.

I finally got around to something today that had been on my to do list for over a year: record a short video showing how to load user stories into www.PlanningPoker.com by copying them from Excel.

Here’s the video:

My thanks to my daughter, Savannah, who learned Camtasia for Mac while I was traveling last week and then helped me make this today.

It’s summer and I’ve been thinking about sailing. I didn’t get to do any this summer, but I can still think about it. Thinking about sailing reminded me of the 1995 America’s Cup race between the US and New Zealand. That race is a great illustration of the importance of both getting close to our customers and of rapid feedback.

To design their boat, Team New Zealand made use of software that would allow them to simulate the impact of various design changes on the speed of the boat. They evaluated thousands of design decisions. Each day the simulations were run on a small network that was located a few feet from the dock. To further evaluate designs, Team New Zealand made two boats and each day would alter one with a design change to be evaluated. The two boats then raced each other to assess the impact of the design change.

By contrast, the U.S. boat had been designed and tested using massive supercomputers. But they were located hundreds of miles from the dock. This created significant feedback delays. Feedback was also slowed because the team had only a single boat on which to test changes.

Getting close to their customer and using rapid feedback cycles led to Team New Zealand winning the America’s Cup for the first time. If you are not cycling ideas past your customers quickly enough to get rapid feedback, consider moving closer to the dock.

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