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:
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:
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”:
The survey also asked which practices where essential for a team to be considered agile. The top five were:
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.
It is perhaps a myth, but an enduring one, that people and their pets resemble one another. The same has been said of products and the teams that build them. If it is true that a product reflects the structure of the team that built it, then an important decision for any Scrum project is how to organize individuals into teams. This paper presents a set of guidelines to consider in designing an appropriate team structure. Each guideline is presented in the form of a question to be asked of a current or proposed team. The questions are intended to be asked iteratively. Ask each question of a current or proposed team, changing the structure as appropriate based on the answer. As the structure changes, re-ask the questions until you can answer “yes” to each.
An effective team structure is one of the most critical factors in the success of any agile endeavor. Poorly structured teams will lead to inefficient teamwork, excessive integration challenges, multitasking, low morale and other problems. By using these nine questions to carefully consider how teams are organized you can avoid these problems.
Nine Questions to Assess Team Structure by Mike Cohn is licensed under a Creative Commons Attribution-No Derivative Works 3.0 United States License.
Based on a work at blog.mountaingoatsoftware.com.