First, let me tell you that I love this book. It covers the techniques that agile development teams use to estimate and plan their projects. It has an interesting and well worked out case study. Second, let me tell you that this post is NOT a book review. If you are familiar with this book, it is probably unnecessary for you to read this post at all. Anyone involved in agile estimating should be aware of these techniques. However, most of the information found in other posts will not involve them directly. Thanks to material like this book, those techniques are well understood. I will be covering other material on software estimating. Some of the material in this blog will be useful to estimators outside of the agile development team. This might include product managers or independent estimators. Independent estimators are usually internal or external consultants asked to take a look at the development project and report about how it is progressing. They usually must render an opinion regarding whether and when it will be completed. By the way, I should also mention how much I respect the author of this book. Mike Cohn has brought much to the agile community between his books, consulting and lecturing. He was gracious enough to acknowledge my contributions to this book, despite the fact that I only made a few comments about the case study. There is one other disclaimer. Some of the information below may be slightly different from the above book. The information below is based on my experience. However, any deviations are not significant with respect to the reader’s understanting of these concepts.
User stories and story points are the primary planning artifacts of an agile project. For example, if a stock trading system were being developed, then there might be a user story like, “as a trader, I will be able to see 15 minute candle stick charts with formations where I expect price changes to be identified.” Another story might be, “as a trader. I will be able to see my account information.” Each story will be assigned story points. The first one might be 8 story points, and the second one might be 4. There are no units on story points. The first might be implemented in 8 days or 8 hours. The only thing we are estimating is that implementing the first story will take twice as long as the second one. Another thing to realize about story points is that there are only a descrete number of values that can be used. Usually, theses are 0 (for extremely small), 1, 2, 3, 5, 8, 13, 20, 40 and 100. What about 4 from my example above? Some practitioners allow the use of 4 but do not allow 3 or 5. Otherwise, 3 or 5 would have had to be chosen for the second example story. In any case, the point is to limit the number of values that story points can take. These are rough estimates. It makes no sense to debate between 16 and 20 when the estimates are so imprecise at this point. There are three things to keep in mind about story points. First, they are estimates of effort, not size. They are not alternatives to function points or feature points. Second, they are relative, but non-standard. Across town, someone can be developing a trading system with the same two user stories. They might assign the first one 40 story points and the second one 20. They are saying the exact same thing, but it looks much different. Third, story points should not be mapped into real time. Even when you think you can implement 20 story points in a week, do not say that a story point is 2 hours. Practitioners agree on this and it will be presented without proof for now.
We talked about story points being assigned, but not how. One common way is through the use of a collaborative technique called planning poker. Planning poker sessions should be informal, like a friendly poker game. If this is the first time story points are being applied to this project, then the team must reach consensus on a story that is roughly in te middle with respect to implementation time. That story should be assigned 5 or 8 story points. The objective is to get a good distribution of story points. Otherwise, we are likely to have a collection of user stories with story point values of only 1, 2 or 3. This would be no better for estimating than a collection of user stories with story point values of 40 or 100. The wider distribution gives more, but not too much, percision to the size estimates. After this, someone reads each story in turn. This is often the product owner. There can be questions or discussions. After this, the team member assign a number of story points to it relative to the middle story. Some companies have decks of cards with each of the possible story points printed on them. The team members can place one card in front of them face down. This is so other people are not influenced by the values already chosen. When everyone is ready, the cards are turned face up. If everyone agrees, then that value is assigned as the story points. Otherwise, the people with the extreme values, lowest and highest, explain why they chose them. There can be questions and discussions. Then another round is played in hopes of reaching consensus. Sometimes, someone will need to expedite the assignment of story points. If the discussions are running too long, then a 2 minute limit should be imposed. This could be done by anyone on the team. If the reader sees that the team is boggng down on whether the value should be 2, 3 or 5 then a value of 3 might be imposed. Alternately, the reader might decide to go with the majority view. In any case, the objective is to get though the stories in a reasonable amount of time. All of the estimates will be continually changing as the project progresses. The best way to learn how much effort is required to implement any user story is to implement user stories. In agile, developing adequate software is more important than developing a perfect plan!
Agile development is performed through a series of iterations. In the Scrum mentodology, these are called sprints. Organizations set the size of these iterations. They can be anything from one week to one month, but organizations are moving toward the one or two week time frames. For each iteration, the project owner identifies the user stories that should be worked on. Remember that the lenth of the iteration is fixed. If the team implements the assigned user stories early, then the product owner looks at the user stories that are not yet implemented and selects some more for the team to work on. If there are unfinished user stories at the end of the iteration, then they are moved to story backlog and tackled in a later iteration. There is an additional planning step associated with iterations. The team must take the user stories and decompose them into technical tasks. These tasks are often only recognizable to developers. There may be a task to create a database. There may be tasks to create API stubs to allow for implementation of screens before some interfaces are ready. They are often assigned to a single developer, but not always. Traditional project managers often think of tasks as work items that will take between one day and one week. Agile teams usually identify tasks that will take less than a day to complete. Tasks are usually estimated using ideal time, which will be discussed next. Some people utilize a measure called task points. Obviously, task points are much like story points in that they do not have specific time associated with it. My experience is that by the time you are at the task level, it is much more natural to start to talk about hours required to deliver something.
Ideal time was a term coined by Kent Beck. It was the amount of time development would take “without distractions or disastors.” At one time, it was used instead of story points to estimate development time for an entire application. There were problems with this. When management was told that a development project would take 10,000 hours of ideal time, they assumed that 5 developers would be done in a year. They assumed the team would bridge the gap between ideal time and calendar time with some unpaid overtime. This was never realistic. The gap was simply too large. Many agile developers only accomplish the development 16 to 24 ideal hours of work in a one week sprint. This would mean that an 80 hour work week would be necessary to deliver 40 ideal hours. This is not sustainable! People begin accomplish less with each additioal hour that they work. The project is doomed. Some teams try to compensate for this by inflating their ideal hour estimates. At that point, they are no longer estimating, they are negotiating. Management responds by negotiating for faster delivery. No one can remember where the estimating stopped and the negotiating for increased time and resources began. This is why story points, which are not tied to delivery time, became the preferred method for estimating projects, releases and iterations. Ideal time still makes sense as a way to estimate the tasks that make up a sprint. The sprint will take a week or whatever time frame the organization has committed to. Management cannot attempt to negotiate an early end to the sprint.
Velocity is the key to traditional agile estimating. If I am planning to drive to a city that is 100 miles away, and my average velocity is 50 MPH, then I should be there in 2 hours. Likewise, if a project has 100 story points left to implement, and the average development velocity is 5 story points per sprint, then it should take 20 more sprints to complete the project. If the sprints each take 1 week, then that will correspond to 20 weeks or about 5 months. Velocity is also calculated for the technical tasks that are done during an iteration. Here, each developer has his or her own velocity. It is calculated as the number of ideal hours that are accomplished during the iteration. Sometimes, it is shown as a percent. For example, if a developer accomplishes 24 ideal hours of work in a one week sprint, then the velocity might be expressed as 60%. Task related velocity is not used like iteration related velocity. There is no estimating of a sprint. If your organization has decided that sprints will take 5 days, then they will take exactly 5 days regardless of the velocity of any of the tasks. The task velocity can serve as a process improvement measure. The closer that ideal time gets to calendar time, the better. However, it is critical to understand the nature of the work people are involved in when evaluating task related velocity. An individual may only be accomplishing 2 days of ideal time work during a sprint because that individual is constantly being used to solve problems that other people are having. If this is the case, then this might be the best use of that person’s time and talents.