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 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 count the number of requirements. Looking back at the historical data, we could then say that a project with N requirements usually 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 was 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’ is 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 it 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.
For more on estimation, take a look at John McFadyen’s article Premature Estimation
Looking to improve your product ownership skills? Check out our Certified Scrum Product Owner training
If you need support with estimation or product breakdown, get in touch with us using the link below.