estimating

implementing scrum part 2

via Flickr by drewgstephens

In this post, I explained that SCRUM is not a silver bullet and that there some significant barriers to entry for organizations wanting to adopt SCRUM. In this post, I’m going to introduce Agile estimating, planning poker, fibonacci, and velocity.

Let’s say that your organization is ready to go, you’ve turned command and control on it’s ear, you’ve identified the Product Owner and you’re going to be the ScrumMaster. You’ve put together a team of seasoned developers, a creative designer, and a QA Lead, but the designer and QA Lead have never worked on an Agile project and they also have never worked with this team of developers.

Let’s say that the Product Owner has put together a pretty comprehensive list of User Stories [let's say that for argument sake that these have been validated and prioritized and you have verified that they follow the INVEST principles...more on that in another blog post]. What now?

First, you need to work with the “Team” to make sure that they understand what their responsibilities are, this includes the talk about being a self-organizing team, that they’re responsible to one another, the Product Owner, and ultimately to the organization to do what they say they’re going to do.

The next step is for the SCRUM Team [that's the development team, the Product Owner, and the ScrumMaster] to decide which items in the Product Backlog you’re going to deliver in the upcoming Sprint. In order to accomplish this, you need to be able to quantify how much time or effort each item on the Product Backlog will require.

This quantification of the Product Backlog is called estimation and is commonly accomplished by having the development team play a game called Planning Poker.

Game playing? Man this SCRUM stuff is wierd. OK, let’s talk about Planning Poker.

The idea behind User Stories is to collect the requirements in bite-sized pieces. The size of those bites will inevitably vary. The Agile solution to this problem is to rate each User Story according to relative “size”.

The best analogy I’ve heard is to compare the stories to dog breed…compared to the other stories, if the current User Story a Toy Chihuahua or a Great Dane? Where in the middle…Jack Russel Terrier? Labrador Retriever? Once each person has an idea for the relative “size” of the item, each person has to play their hand, and the group consensus wins…highest and lowest have to explain why they think the feature is larger or smaller than the rest of the team.

When I do this, as the ScrumMaster, I intentionally don’t play a hand because I don’t think I should influence the team’s collective insight into how big or small a feature is. To each their own. The planning poker deck we use was purchased from Mountain Goat Software and was well worth the few bucks it cost. There are online versions and of course with a pair of scissors, some index cards, some markers, and a little free time you can make your own.  The important part is that you understand the notion of the relative scale of accuracy and the variability that is introduced as a feature gets larger.

You’re probably familiar with the Fibonacci series of numbers. We use this series of numbers to incrementally scale the “size” of a feature. Why do this at all you ask? Well, if I ask you to estimate in inches, the distance from the tip of your index finger, where it currently is, to the tip of your nose, you will probably be able to estimate with better than 85% accuracy. Now if I ask you to estimate using the same criteria the distance from the tip of your index finger to the middle of the letter “O” on the nearest Stop Sign [depending where you are right now] you might be able to estimate with a significantly smaller degree of accuracy, and finally if I ask you to estimate, in inches, the number of inches from the tip of your index finger to the tip of the Empire State Building in New York City, you are likely to have an accuracy approaching 0%.

With this in mind, we use the Fibonacci sequence because as a feature increases in size, our inherent ability to accurately estimate it’s size diminishes. After all of the items on the backlog are estimated, the next step is to determine the Sprint Backlog…the estimated subset of product features that will be addressed in the Sprint. We had a hard time understanding how much we could bite off in our first few sprints [in other works, how many "story points"...or Fibonacci values we could consistently complete in a sprint].

In order to get around this, we took two decisive steps.

First we committed to micro (one week) sprints and second we intentionally rigged the sprint backlog with items that we knew were small enough to complete in a week, yet big enough to validate [one way or another] our estimates. This process allows us to determine our “velocity”. Velocity is the average rate at which a team can complete story points for a unit of time. Once we were able to determine out weekly velocity, we were able to extrapolate our bi-weekly velocity.

Once we were able to determine the velocity for a “normal” sprint, we have become increasingly confident in our ability to deliver on that velocity. I will put in a big caveat…the velocity statistic is only a general guide, and as you adopt SCRUM, the accuracy of the velocity is only as good as your ability to limit the variability of external change within the team. In other words, if you determine the velocity for a specific team, that velocity will be affected by making changes to the team, and even in some cases by changes that the team may make from within.

For more information on these topics, there is a great book on this topic written by Mike Cohn called “Agile Estimating & Planning“. I highly recommend it.

{ 9 comments }

Estimating Effort: Part 5

by Bill Duncan

piece-missing-emptyIn this last article of the series, I’ll cover a potpourri of other estimating topics including dealing with poorly defined work and what to do when management thinks it should cost less or take less time.

Dealing with Poorly Defined Work

In order to introduce the basic concepts of effort estimating, we limited our discussion to developing an estimate for a single, reasonably well-defined activity. Although this type of work may prevail in some project environments, most projects will have a significant amount of work to estimate that is not well-defined. In this section, I will cover some approaches to those situations.

No one on the team has experience with this kind of work. Here are some ideas that should help:

  • Find someone who does have experience, e.g., a consultant or someone in the organization who is not on your team.
  • Use a wider range estimate to reflect the greater uncertainty. Unless the unknown work represents a significant percentage of the total work, your overall project budget will not be greatly affected. Remember that we are willing to tolerate budget variances in individual work items as long as the project total is acceptable.
  • Break the work down into smaller units. Often, you will find that you do have experience with much of the work. The aspects that you don’t have experience with can be handled with a wider range estimate.
  • Develop some experience. It may be possible to have one or two team members do a couple of “practice” activities as part of the project planning process. I used this approach quite successfully as part of a database conversion project several years ago.

This is truly state-of-the-art stuff. See previous paragraph, especially the last bullet.

We really have no idea of what’s required or we don’t know enough at this point to define the work. Neither of these two complaints is an estimating issue; they are both either a scoping issue or a risk management issue. They might also be a defensive response to a skeptical manager. If so, see below.

Conflicting Estimates

Did you ever have two team members who differed widely in their opinions of the likely amount of effort required to complete a work item? Range estimates can help, particularly if the individuals involved are inherently optimistic or pessimistic — if their ranges overlap, it is usually much easier to reach agreement.

But the root cause of such difference is most likely to be the presence of conflicting assumptions. For example, a team member who assumes that previous design work can be reused will produce a lower estimate than one who does not. By surfacing the conflicting assumptions, the team can discuss the alternatives and decide what to do.

One particularly pervasive assumption is the skill level of the person doing the work. Estimating is often done by more senior staff, and they tend to think in terms of “how much effort would I personally have to expend to complete this work.” This is likely to produce an estimate that it too low. At the same time, they may become aware of their tendency to overestimate and overcompensate. I recommend that you remind your estimators to constantly assume an “average” resource, and to recognize that it will take 2-3 projects of comparing actuals to estimates for them to get good at knowing what “average” really is.

Converting Effort into Duration

I know that I am going to get a lot of flak from some of my colleagues about this next point. The technically correct answer about how to estimate duration is that you should do just that — look at the effort estimates and develop a three-point range estimate of the duration for each work item. For example, with an effort estimate of 30, 40, and 80 hours to be performed by a single individual working fulltime on the project, I think it is reasonable to predict that this person may need more than two full weeks to get this item done if it ends up requiring 80 hours of effort.

In addition, since virtually all network analysis techniques (Critical Path, Critical Chain, PERT, etc.) underestimate the most likely duration of the project, many would also argue that a Monte Carlo simulation is a necessity. And I would agree … if you’ve got the budget.

If not, take the easy way out — take the effort budget (the expected value of the effort estimate) and convert that into a single-point duration budget based on the availability of the individual assigned.

Maintaining Your Estimates

If the work of the project changes via an approved change order, you will need to estimate the new work and update your budget as well.

If any of the assumptions that went into your estimates are changed, you should also update your estimates. In this case, you may not be able to modify the budget, but you should still re-estimate the work. For example, if one of your most skilled staffers was supposed to work on Work-item D, and due to circumstance beyond your control D is being done by an intern from the local community college, you better reset everyone’s expectations about how long it is going to take.

Management Cuts It in Half

The first thing you have to do is find out why. Most such management actions are created by one of the following misunderstandings:

  • Your manager may not understand the difference between an estimate and a budget. Educate them. But in the nicest way possible if you want to keep your job.
  • Your manager may view your estimate as a negotiating position. Some managers assume that you have “padded” your estimate to provide negotiating room. Again, educate them — explain how the suggested cuts will either reduce quality or increase the risk of an overrun.
  • Your manager’s cuts may be a negotiating position. Most good managers understand that a more difficult task (where the target is aggressive) can serve to motivate the project team. But even good managers often fail to appreciate that an impossible task (where the target is so aggressive that it is clearly impossible) is a powerful demotivator.

Summary

Underestimating will drive you crazy. You will spend endless hours explaining why you are over budget and behind schedule. You will spend endless hours dealing with unhappy customers and stressed out team members. Overestimating may not be much better. Your projects will not get approved because they will be seen as too expensive. You may even lose your job if your padding is viewed as unethical.

Three-point estimates for effort may not get you into heaven, but they will make this life a lot more rewarding for everyone affected by your projects.

{ 0 comments }

Estimating Effort: Part 4

by Bill Duncan June 8, 2009 Estimation

This is the penultimate article in a series of five on effort estimating. In the first, I focused on definitions since many people use terms such as estimate and budget as synonyms when, in fact, they are very different. Here is a brief recap of some key definitions: Estimate. An informed assessment of an uncertain [...]

Click to continue…

Estimating Effort: Part 3

by Bill Duncan January 5, 2009 Estimation

Preparing Three-Point Range Estimates The mechanics of preparing three-point range estimates, particularly if you are working with team members who have never used the technique before, are important. And just a reminder: we are still dealing with effort estimates; duration estimates come later. Working one-on-one. Let’s again start with a simple case where you need [...]

Click to continue…

Estimating Effort: Part 2

by Bill Duncan December 17, 2008 Estimation

This is the second in a series of articles on estimating effort. In the first, I focused on definitions since I find that many people use terms such as estimate and budget as synonyms when, in fact, they are very different. Here is a brief recap of the key definitions that I will use: Estimate. [...]

Click to continue…

Estimating Effort: Part 1

by Bill Duncan December 5, 2008 Estimation

This series of articles is extracted from a similar series I wrote for Projects@Work a couple of years ago. I’m posting it here in reaction to my review of Josh’s articles on Earned Value where he (in my opinion) used the term “estimate” when he should have said  ”budget.” Many of the terms related to [...]

Click to continue…