The purist in me loves the concept of no estimates. Imagine a world where designers could just design until everything looked perfect, developers could just code until everything worked exactly the way they wanted and at the end of it all, whenever that might be, their labour of love is packaged and delivered to the happily waiting customer.
Let’s all take a moment to get realistic. The whole elitist, self righteous attitude towards the entire #NoEstimates movement needs to stop. Would you take your car in for an MOT and tell the mechanic to do whatever work needs completing to meet your goal of passing the MOT without expecting an estimate? Absolutely not. Would you call a kitchen fitting service, tell them what you want your new kitchen to look like and then let them install everything before giving you a price? Don’t be ridiculous.
I’m afraid the same is true of software development. If you think for one moment that any respectable organisation is going to give you a blank cheque and let you get on with the work, then you’re very much mistaken. You shouldn’t frown or tut when asked to provide an estimate because it’s an absolute necessity. Whilst we all understand that software development by its very nature is difficult to size, if you’re confident in your ability and in your process, giving an estimate at the right level (more on that below) should be easy.
What we should be focusing on is not removing estimates from the process, but turning estimates into something that are actually useful. I am under no illusion that education is required to achieve this so that people truly understand what an estimate is, but by trying to cut out estimates you’re just adding to the problem.
We need to be pragmatic. I’m not suggesting for one moment that we should give management a “man days” estimate for a project – that’s unrealistic and would just set everyone up for a fall. In my opinion however, it is realistic to perform a sprint level estimate which has the added benefit of getting your epic user stories in order and into a storymap before you begin. It’s a remarkably straightforward but powerful way of understanding how much work is ahead of you.
Get the entire team, including your Product Owner, together for the day. If you can, go off-site somewhere. Have the PO talk you through the project – the vision, the goal and of course the epic user stories. If you’ve got any supporting wireframes or designs – great. Once you all understand what it is you’re being asked to build, it’s time to revisit each epic one by one and talk it through in a little more detail. Based on what you know, ask yourselves as a team “is this something that can be tackled within one sprint?”. If it’s too big, then break it down until it does fit in a sprint.
Move onto the next epic. “Can we fit this in the same sprint as the last epic?”. If not, it goes into a new sprint. Rinse and repeat. At the end of it, you’ll be left with a storymap of the entire project – based on what we know now, of course. Ultimately this will eventually lead to the team feeling confident about saying that they need around N sprints to complete the work. From this we can create an indicative sprint plan and the estimation requirement is satisfied.
Of course, the usual caveats apply – this sprint level estimation is only based on what we know now and can only take into account the factors that we have considered at this stage. The detail will come in the sprint planning, but this should be enough detail to give both the PO confidence that you understand what needs to be built, and importantly the customer will have an idea of how much they will need to invest into their new project.
We don’t know, or want to know all of the detail up-front and this form of estimation caters for that. Be confident to provide an estimate like this and don’t shy away from it. Make sure your stakeholders understand the level of estimation you’re providing but be realistic when you provide it. Kicking off a project in the right way is essential, and starting with a good understanding of the goal, a storymap and an approximate idea of how many sprints will be involved is an excellent place to start.