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.