Skip to content

Criteria Driven Estimation

A while ago a client created a focus group to look into the whole software development life-cycle. they were to suggest a new standardised way for the business. Mainly consisting of technical leads the group asked for other people’s ideas and contributions.

At the time one area of particular annoyance was the estimations required before any project could be started. Days were spent deciphering requirements documents, converting them to features, epics and stories, and then estimating the time required for each.

A colleague and I decided to offer a proposal. Nothing radical. No getting rid of estimation, as much as we’d like to have. Something quantifiable and within the organisation’s comfort zone. Well, we thought so.

What we came up with was just an idea, not something that we’d used before. We saw it as a proposal to experiment a bit in the area.

The Idea

The best ideas are simple. I’m not claiming that this is the best idea, but it is simple.

We’d receive a document from the business, architect, however. Within the document would be any number of high level requirements that needed to be fulfilled within the project. What we wanted to do was simple count the number of requirements. Looking back at the historical data we could then say that a project with N requirements normally takes between X and Y iterations to complete.

A ballpark figure, nothing more.

However, that may have taken a couple of team members an hour or so. No expensive effort undertaken. If the range is acceptable then the requirements can be looked at from an acceptance criteria point of view. The same historical data can be extracted and a new range X’ to Y’ given. Hopefully a smaller range than before. This could then be repeated at the acceptance test level.

Each stage of this gives the business a better idea of when a piece of functionality is likely to be delivered, and therefore whether is a priority – or even worth doing.

The Result

So, this idea was put forward to the focus group. No estimation of the whole project was not an option for the organisation, they just weren’t comfortable with the idea.

What came back was “less than ideal”. What else can you call a process whose first step is to provide an estimate of how long the estimation will take?

I’ve still not managed to test this idea out. It requires a good chunk of previous project data (which my client had). In my mind, however, the idea is still sound.

If you get a chance, and want to, give it a go. Let me know what happens.