Estimating

I was flying home from a client visit last week at the airport getting ready to board the plane when the gate agent announced that the flight was gonna be delayed by ten minutes due to some unspecified mechanical issue. Ten minutes later they announcement another ten minute delay. They did this two more times.

So what was going on? Did the airlines not want to admit upfront that they had a 40 minute delay so they fed the delays to us ten minutes at a time? Or did the person who is doing the work really not understand how long it was going to take? I started thinking about how common it is for people to not be able to provide good estimates. Sometimes they underestimate the complexity, or maybe student syndrome sets in, or they're just overly optimistic.

It was ironic, but part of the work with my client that week was explaining the technique of relative estimates using t-shirt sizes and story points. The team I was working with was  new to agile and used to the old way of doing absolute estimates, which as we all know are not as accurate because of things like student syndrome or Parkinson's Law.

So how do we get better at estimating? I think the real question should be how we recognize estimates for what they are. An uncertain prediction of a future event. Even when we use story points, we won't know our true velocity until after a couple iterations when the team has time to come together. At the beginning of the project, we need to recognize how much uncertainty we have. So instead of saying "that will take about 2 months" we should say "that may take 2 months, but it could take as long as 3 months." So we provide not only the estimate but some measure of the uncertainty that goes with it. Similarly, if we think a story might be 13 points, but there's a lot of uncertainty, we should state that and make the story 20 points (or 21 if you're being strict with your Fibonacci sequence). Now if only I could get the airlines to provide a more accurate estimate the next time there's a delay...or at least how certain they are!

Scope

I'm finishing up the development stage of a project this week. It has been an interesting road with respect to scope. I was brought into the project after the start, actually 8 weeks into the project. When I got here, I looked at how much work was planned and became concerned. Without trying to validate the estimates, I felt there was more work than we could get done by the end of the project.

I worked with the team and client and we were able to reduce the scope by about 20%. Some of this was moving stories into the next release. Some was reducing the complexity of what we were trying to deliver.

As the project progressed, we added more scope. Not a surprise; it should be expected. As the users started seeing parts of the application, they thought of other things to ask for. But here's where we ran into a bit of a jam. We added new stories, but didn't take anything out. We assumed we could absorb the additional work; it only was a couple story points a week.

With about 4 weeks to go, as I looked at our velocity and how many points we had left, I saw we had a problem. When I brought this to the business, they said "we have to have all of this, you need to work harder." Two weeks later, the business saw what I was talking about, it just wasn't all going to get done.

The business identified some stories that could be moved out. The remaining work was still more than our average velocity, so I agreed I would work the team through the weekend to get the rest of the work done.  This was the first time I had asked the team to go above their normal work days, so I wasn't to concerned. If we had been 4 weeks out and expecting 4 weekends of work, I would have been concerned.

We got the work done. Our final tally was slightly higher than what I thought we could deliver right after we re-scoped the work. The real lesson to me is to make sure every time we add even a small amount of work, we make the client aware of how that can impact what we can deliver by the end of the project (their final delivery date couldn't be changed).

Burndown Charts and Student Syndrome

I have a client that has a tendency to get nervous about half way through each iteration because the burndown chart isn't tracking. Each member of the team is giving a daily estimate of how much work remains. The catch is, each one is accounting for some uncertainty in testing/integration, so they are padding their estimates with a buffer.

The problem with the buffers can happen in agile or waterfall projects. I can remember the old days of project management...I would be working on the schedule. I'd go to the various team members and ask them how long their tasks would take. They would add in a "fudge factor" to account for any uncertainty. Then when it came time to do the work, they would procrastinate on starting, knowing this buffer was there. However, when they did start (later than they should have), they would come across the uncertainty and now their buffer was gone and the project got behind schedule. This phenomenon was referred to by Eliyahu Goldratt as Student Syndrome.

The trick of course is not to put the buffer into each estimate in the first place. In my client's case, what has happened over the last couple interations is that all of a sudden at the end of the iteration, everyone gets their work done, doesn't need the extra buffer, and the burndown takes a sharp nosedive. The only real issue is that the PM taking unnecessary steps during the iteration to try to fix a problem that doesn't exist (and try to explain what is happening to management).

Estimating

I was working today with a client on estimating how many man-hours their project was going to take. It was a pretty straightforward exercise; estimate the number and complexity of all the components of the project and apply benchmark data we’ve collected and add it all up to come up with a total. At this early stage in the project, there is some margin of error in what we refer to as a budgetary estimate. It’s more refined than a level of effort but not a detailed estimate.

The resulting answer was pretty big and the client thought it was much bigger than the project would actually be, and he might be right. Under ideal conditions, the project may take much less time. However, having done projects before, I know this perfect state for project execution is rare. Things often come up. There’s some requirement that didn’t get identified but is a must-have. Problems creep up. People get pulled of the project for something else, or quite or get married. Some features take longer than the benchmark would indicate.

For now we’ll keep an eye on this estimate while we start our first iteration. After we complete that, we’ll see if our estimates for those features match reality. Then we can adjust the overall estimate as necessary.