In the previous post in this series ( High-Level Project Estimation: Overview ), we discussed why good estimates are important and what to be aware of when creating an estimate. This post reveals how to actually create estimates.
How do we turn pages of feature requests, wireframes, and miscellanea into something you can estimate? My first step is always to quickly review all the documentation provided to get a high-level understanding of what the client wants, what their experience with software (and consultants) is, and what constraints might be in play. While reviewing the documentation, I take notes that help me think about the project:
- What technologies would we use to build this?
- What technology constraints are present? (e.g., IE8, mobile responsive, native mobile)
- What immediate questions or red flags are jumping to mind?
- Is there something that doesn’t make sense after first reading?
Once I’ve identified these things, I go back through the documentation a little more thoroughly. This time, I’m looking for nouns. What are nouns? Nouns are:
- an object that would be a database table (or a Rails Model). Example: “User”
- an integration with an external service. Example: Use Joe Schmoe’s API for data.
- anything that I think will take about a week to implement. Example: Integrating with an external OAuth system.
I list out all of the nouns I think might take about a week to implement. Once I have my list, I review it. Some items might feel like less than a week, some more. That’s ok (remember, it’s an estimate)! Now that I have my nouns and I’m happy with all of them, I count them. So, if I have 10 nouns, that points me towards the work taking 10 weeks to build. If an estimate requires more precision, I might break features down into smaller pieces and estimate in smaller increments (e.g., developer-days). Spreadsheets are your best friend in this piece of the process.
But we’re not done yet! Keep reading.
There are lots of unknowns in building software:
- We don’t always know who will be working on the project.
- Clients change their minds. Features change.
- Scope creep: you can fit just one more feature in, right?
- Sometimes development or design gets blocked.
How do we account for these and other variables in your estimate? Not to mention things that are a bit more quantifiable, such as our agile process rituals (e.g., sprint planning, backlog grooming). One method is to add a percentage of the calculated time to the total estimate. I frequently use 30%. Yes, I buffer all of my “I think it will take x weeks to build” with THIRTY percent. I’m saying that however long I think this will take, add more than a quarter of additional time, and that’s how long it will really take. While this may feel like a high amount of “unknown”, in my experience it works well in accounting for the variables discussed.
Once I’ve done this, I take a second-look at my estimate and adjust up or down. Some of this is about gut feeling. Do I really think it will take that long? If it feels too long, I’ll re-evaluate my individual estimations. Would that feature really take a week? Critically evaluating my own estimations in this way ultimately gives me an estimate I can be confident in.
While reading through the information provided about the project, it’s think critically about what’s being presented. Are there features that feel like icing, rather than necessity? Are there feature requests that might even be a bad idea? Take note of these things, with a quick explanation of why they might be eligible for removal. What would we de-prioritize if we found out a potential client’s budget is lower than our estimate? This information can be vital for sales to negotiate a contract, and in any regard shows that we’re thinking critically about their product. Questions to consider include:
- What are the vital feature to make this application serve its purpose?
- What is the least important features for meeting the client’s goals?
- If the client need to cut features, are there any in particular you’d recommend?
- Are there any features that might be overly expensive (in time/budget) to implement? If so, is there a simpler alternative?
Estimating is tricky work. We must think about not just what the potential client says they want (in their documentation), but what they actually want and what they really need, whether they realize it or not. When I estimate a potential project, I estimate how long I think it will take us to build, but also point out risks, red flags, hidden work, and questions I have about the project. My goals are to provide an accurate estimate based on the information I have and to highlight things that might affect my estimate.
Even though I try to arrive at an accurate estimate, it’s still just that: an ESTIMATE. At Quick Left, we encourage our clients to start our relationship with what we call a Discovery Sprint. A Discovery Sprint is a collaboration period (from a few days to two weeks) in which we explore features in depth, write user stories, do some up-front wireframing and design. All of this gives us a chance to get to know each other a little better and more accurately understand the project ahead. Having that improved perspective and more well-defined user stories allows us to re-estimate.
What do you think? Are you ready to be a master estimator? In the third and final post in this series, you’ll get to try your hand at it with some sample materials. Head over to Let’s Practice! to give it a shot!