No Estimating, Really? Give me a break

What's with this whole #noestimates movement? It's a group of Agile enthusiasts advocating not to estimate and not 'plan out' work. Their reasoning: 'because the estimates are always wrong anyway'. I find this concept of not planning or estimating disturbing and unrealistic in most situations.

Don't get me wrong, if you have a team of employees building out a continuous product for a company, then sure if you can get away from estimating, great for you. The project goes on forever and then you're right, probably no need to estimate. 

Unrealistic

BUT, if your team does not fall into the case above, choosing not to estimate any aspect of the project is unrealistic, and dare I say, an idealistic viewpoint on the part of the #noestimates movement. 

In the not too distant past, I led a team that was building a continuous product. What I found is that 9 out of 10 times you do, in fact, have to give an idea of "when it will be done." Nowadays, I'm leading a team that specializes in custom software development services for paying clients. It would be unrealistic to tell the paying client that his project will be "done when it's done." 

I have agile-based contracts with my clients. And while I'm all for "customer collaboration over contract negotiation", a new client is not going to spend money or commit to a contract without having some sense of the cost and the timeline.

We Always Estimate

My team always estimates. Even before we've started the work, we estimate the whole first release. We story point everything. To be fair, our team has gone through forming and storming and bounces back and forth between "norming and performing".

If a potential client is unfamiliar with the agile/scrum process and has no experience with me and my team, there is little I can tell him/her that will persuade them to take the risk of hiring our team without giving some estimate.

Historically

I am proud to say that to-date my team has been very accurate in our release plans. Every project has fallen within 1 or 2 sprints of our original projection. We never give a specific date. Instead, we give a range. Project "A" will take 9, plus or minus 2 sprints. Over the last several years in building products for clients we've yet to miss this mark. How are we consistently able to deliver on our estimated release dates? Please continue reading to find out.

Why it works

I have something many other companies don't have. I have a co-located, dedicated team that has learned to work with each other; they know each other's strengths and weaknesses. I have a team that has experience with various projects and functionality needs. So when they estimate, they estimate the same (no matter the project) on the basis of functionality and effort. This keeps their Velocity the same from project to project.

What we do

We sit with the client and facilitate a story mapping session. During this session, my team is listening and sizing the work as we break it down into User Stories. The client is adding a solicited business value ranking and together we determine the Minimally Viable Product (MVP). 

Once the story mapping is complete, my team will seed the Product Backlog and then have a healthy Product Refinement session. We double check, size, and re-size all the epics and stories. In some cases, we'll break down the stories if they're more complex. 

We then lay out the first two-week sprint based on our known Velocity. This concept is the key to it all. I have a team who works together on each project, keeping a consistent Velocity, and because of that, the estimates are consistent. We do a mock Sprint Planning on that first sprint and break down the tasks. Based on the outcome of that activity we may adjust what we think should be in Sprint 1. We then quickly lay out the rest of the work based on the Velocity. We'll add in a couple of stories every three sprints for unknowns or defects. This gives us the total # of sprints needed to complete Release 1.

Short Example

Using the method above, let us say our team calculates that it needs 14 sprints, plus or minus 2 sprints. We propose to the client that it will range from 12 to 16 sprints. Now that we know the sprint count we can also give them an estimated cost.

Let's say 2 team members and a Scrum Master cost $25,000 for a two-week sprint. This project will cost from $300k to $400k. It will be delivered in 24 to 32 weeks from the start date. Sure that's a big gap. My team knows it will be closer to the 12 sprints at $300k range. However, over the course of the project we allow room for course-corrections or new features to be added. We typically will guide our client through this and show them how the total budget is affected by changes they introduce into the backlog.

Back to Estimating

Paying clients have to have some idea of the timeline and cost associated with a given project. We have to be able to provide some proposal to get the work. Neither of these activities would be possible without estimating.

When do we not estimate?

You know when we stop estimating? Never! BUT, once we have established trust with a client and they see how the Scrum process works, there is less of a need to estimate. Typically by Release 2, they "get it" and we just build and push to production consistently until the project is complete or until they want to stop. We will always estimate stories to get an idea of our Velocity changes for future projects, but for an established project, continued estimating is not as important.