Estimating or Guesstimating?

Everybody would like to know in advance all informations, risks and variables when they need to estimate something. The purpose of estimating is manifold, so we always have to give our best because a wrong estimate might reflect on many things.

What we always have to remember is that we seldom can estimate on a completely solid ground. That's why we normally introduce a corrective factor, which is absurdly big at the start of a project and narrows while the latter proceeds.

Sometimes you lack important pieces of information, nevertheless you have to guesstimate. It should be clear to everybody (at least it is crystal clear to me) that if you guesstimate an effort of 100 it could actually be a value between 60 or 160 (PMI says between 75 and 175, which is a more pessimistic but probably better correction). Guesstimates are not contracts, and they cannot (they shouldn't) be used against you. Thus, we must not be afraid of guesstimating; it often helps us to clarify some aspects of what's ahead of us.

"I don't have enough information" is a very good justification, and it must be respected, but it cannot be an excuse. I know it can be subtle, but that's how I see it. After all, as an old keyring of mine reported...

right or wrong, I'm still the captain

Estimation techniques

I posted some thoughts about it in this discussion.

Estimating blasphemy?

I am working with my team on a new project; we still are in the Inception phase, so even if our ideas are quite clear there are also many foggy aspects. Anyway, we've identified almost all the stories we shall need (the domain is well known) and we are estimating them with story points.

This project will be quite different from all the others we've worked on for many different reasons, so there will be a lot of uncertainity; I then reported to the management that our first estimate will actually be a guesstimate, thus possibly ranging from 60% to 160%. The Project Management Institute (PMI) has an equally broad, but more pessimistic, range for this stage of the project (75% to 175%).

As expected, the management reaction was less than cold, and I was told we had to narrow the gap between the worst and best estimates - a perfectly legitimate request. The problem is that we do not have enough informations at the moment, and only when we'll have an approved product definition we will be able to get to an 80% to 125% range (close enough to the PMI budgetary estimate), but luckily that should happen in a few days.

I'm afraid that will not be enough, because the second question after "how big will it be?" is always "how much will it take?", which obviously leads to "how much will it cost?". Estimates in story points are only a pure measure value, and a duration must still be derived. We cannot use our historical velocity values because, as said, this project is very different from the ones which generated them, so we'll have to run at least a couple of small iterations, observe the values and make a more or less reliable forecast.

Luckily our managers deserve their jobs and they understood our motivations, so I've been able to reach an agreement upon a spike in which we will very lightly touch all the layers of the application and the new technologies we've identified in some previous pilots.

This was another example of how an honest conversation can lead to a win-win situation: the team will not have the pressure of an irrealistic plan and the management will be able to take decisions and actions on the basis of sufficiently reliable informations.

Agile Estimating and Planning

Yesterday I finished reading Agile Estimating and Planning by Mike Cohn. I found it quite interesting, even if id didn't add very much to what I had found in other readings; the good thing is that the whole process is explained, delving into different aspects (some of which are too lightly touched, in my opinion).

Estimating in Ideal days

When it comes to estimating you have different options to pick from; two of the most common are ideal days and story points, each of which has its own strenghts and weaknesses. One of the worst weakness of the ideal days method is that an "ideal day" means very different things to different people; moreover, different team members give very different estimates depending on their relative skills, so you can have a very wide range of estimates for a single item to deliver (call it use case, user story, feature, you name it).

If you're used to ideal days estimating and decide to stick with it, there are some tips that can help you to reduce the risk associated with the method.

The first (and obvious? unluckily not so much...) tip is to let who will actually develop the software do the estimate. Managers do not have enough informations, so they must trust the team. After all, a great slice of management work is to select collaborators, so if a manager trusts himself (and you bet she does) she must trust the people she has chosen as well.

Moreover, more than a single member should estimate the same item; actually the whole team should do it, thus exposing - early - different points of view; more often than not, if somebody estimated an item much less than other members she forgot something or did not considerate all the implications of the item: the key to effectiveness of this practice is the constructive dialogue between developers. A particular way to do it is planning poker: all developers have a deck of cards, each of which indicates a valid estimate; a moderator reads an item from the list to be estimated and each developer choses a card, then everyone turns up their card at the same time. If the estimates are more or less alike there is a short conversation and an agreement is reached, otherwise there can be a deeper discussion, after which there is a new turn.

A deeper problem emerges when developers are differently skilled: they might agree on the relative size of the items, but their estimates will differ greatly; an item which would take an experienced developer two days could require ten from an inexperienced one. On the contrary, if all developers in a team have more or less the same skills they can ignore the problem. If that is not your case (and surely - and unluckily - it is not mine) you have to deal with the problem of scheduling also: if you estimate on the experienced developer's words you have to assume that she will do the work, but you cannot have the guarantee that when the time comes she will be available, so you'll have to spend ten days but you can bill for only two of them; if you choose to take the estimate of the inexperienced developer the customer could complain because your team costs too much. In this cases I normally estimate somewhere in the middle and do all I can to have the two developers pair on the item to leverage knowledge and experience.

Last but not least, ideal days are different for different people: someone consider ideal days as "eight hours focused on a single task", someone else as "six hours focused on a single task, plus a couple of hours on different things". Obviously that brings to different results, and the bigger the project the worse the outcome. That also clashes with scheduling, because people should manage their time but that is not always easy, particularly regarding how to deal with (internal and external) interruptions. To deal with this risk you have to know the velocity of your team members and of your team as a whole, so that you can translate their estimates into sufficiently reliable schedules.

Most of the advices are also useful for estimating with story points.