Our situation is even more complex with individual developers serving in multiple teams and sometimes in a team of one!
Getting to consistent estimates across this various scenarios is not easy. In this entry, I will share some of the tips we have found to work in the past.
Find a common denominator
Estimates usually come in two flavours, days or story points. Ideally, estimates should always be in story points from which you derive days of work.
Unfortunately for most people, story points are just not intuitive. This means they make a great tool for establishing the work to be done but not a particularly great one for communicating the same.
Thus to establish consistency in communication, all our estimates are communicated in ideal days.
To be sure, this has come back to bite us once or twice where the client confused ideal days with calendar days but all in all the gains in shared understanding made for a worthwhile trade-off.
Review stories from similar past projects
Hofstadter’s law states:
It always takes longer than you expect, even when you take into account Hofstadter's Law.
Obviously, this is not a physical law, but you would do well to be mindful of it.
Thankfully, well measured past projects cut through our biases and reflect on us the truth.
For example, one of the more successful projects we worked on, our initial estimate was 5 months, as an e-commerce platform we were sure we understood everything related to it. In the end, it took 8 months from the first commit to a fundable version.
In current projects, we keep this hard lesson in mind as we think of the estimates we provide to clients. Particularly if a client wants a similar application, we now know how long it takes to get it done.
By having such a repository of past projects and the time it took to complete it, disparate teams can base their estimates on them and come up with consistent results.
Estimate some stories together
I expect developers to be very good at writing clean code that has a solid architecture with minimal coupling. I am however quite forgiving if they are not exactly masters of the black art of software estimation.
Still, the more estimators you have, the better. Groups will do wonders to the quality of the estimate.
Even if you will need the developers or individual teams to do their own estimates, it still makes sense to have a session where you work on it all together first.
How do you ensure consistent estimates in your organization? Talk to me in the comment section below or on my twitter @jchex