Many years ago I worked with a team that seemed to be delivering software only very slowly. There were multiple causes, as is usual in these situations, and part of the remedy was to simplify their estimation along with delivering each change as soon as we’d completed it. So we wouldn’t wait until the end of an iteration, or until other pieces were complete, before deploying any change.

The simplified estimation mechanism I proposed worked like this. Instead of estimating work as points in a Fibonacci sequence, which was their approach and is widely used, a piece of work would be estimated to be either Small or Large. However, combined with many other simultaneous changes we quickly saw even that was too complicated. This binary-looking system was actually a ternary system, because a piece of work could also be “too large”. Also, there wasn’t any real consequence to saying something was Small, as opposed to Large. So we quickly simplified it. A piece of work would be estimated simply as “small enough” or “too large”. Our definition of “small enough” was anything we thought we could start and release within five working days.

Overall it worked well. Our stakeholders lost the fine-grained information of having a total estimate for any one project, because it doesn’t make sense to add up, say, 27 “small enough”s, but they won by seeing work delivered much more frequently, and being able to steer better as a result. Things got much better.

Some years later I worked with a team in a very different situation. They didn’t estimate at all, they did deliver quite consistently, and they were well trusted by their stakeholders. Estimation was seen as an unnecessary overhead. But very occasionally they had a different problem: any one piece of work would sometimes turn out to be much more work than some people expected. It wasn’t terrible, but it was an annoying blip for an otherwise very performant team, and—as one might hope—they strove to do better.

As a result, the team considered introducing estimation. They weren’t enthusiastic about this, so proposed t-shirt sizing rather than numerical points, because they thought they’d get less hung up on a simpler, non-numerical, system. But after a brief discussion we realised even that was too complicated. The cause of the occasional overruns, it seemed, was that although the team did all have an idea that any piece of work should only be tackled if it was small enough, they had never explicitly agreed the limits of that among themselves and their key stakeholders.

So we picked up that system I had used years before in different circumstances: Before embarking on any single tech change we would always confirm that it was “small enough”, and we agreed (coincidentally) that meant being about five working days from start to finish.

The vast majority of teams I work with estimate their work using points in a Fibonacci sequence, and of all the problems they might have, that’s rarely one of them. That’s the standard way of doing things, and it’s typically fine. However, we shouldn’t take these common systems for granted. Sometimes it’s the right thing to tweak them… and if we can also simplify them, so much the better.

Photo by hehaden