Welcome back to the “How to Excel at High-Level Project Estimation” series. You’ve made it to the third and final post! In the first two posts of this series, I discussed how to scope potential projects at a high-level and what you should be aware of while estimating. If you missed the earlier posts, you can find them here:
In this post, you get to try it out yourself! I’ve made up a sample feature set to estimate and a worksheet to help guide your estimation process. After you’ve tried it out, I’ll discuss how I estimated this potential project and what questions, concerns, and idea I had while conducting my estimate.
To practice project estimation with your own project, download the worksheet and follow along.
The sample feature set, believe it or not, is similar to things I’ve received in the past. It’s a simple list of features, but there’s a lot of information in there! There’s also a lot of information missing. Your challenge is to review the document you’ve been provided and determine how long this project would take to complete.
The estimating worksheet is intended to guide you through the estimation process. It includes reminders about what to consider, space to note red flags and unanswered questions, and room to calculate how long you think the project would require. For a refresher on the meaning behind each piece of this worksheet, refer to the second blog post in this series, The Art of Estimating.
Now it’s your turn! Once you’ve completed the worksheet and feel comfortable with your estimate, come back and compare it to how I estimated this project, following immediately (don’t peep!).
How did you do? Do you feel confident in the number of weeks you arrived at? Let’s walk through the worksheet together.
This question is meant to get you thinking about how you might build the application and how the features might fit into an appropriate technology stack. Will it need a separate backend API? If I were building this project, I’d probably use Rails with a front-end JS framework.
When a time or budge constraint is present, the question often changes from “how long?”, to “can we do it and how?” In this case, there are no time or budget constraints.
My biggest red flag on this project is around the “cat gifs gallery”. It feels a bit out of place, and maybe not fully thought out. If I were going into this project, I’d want to spend time with the client exploring what exactly they’re thinking, and how it helps them achieve their goals. Another potential risky piece is around the ads. How do they envision ads integrating into the site? Not a red flag, but something worth more discussion.
In this scenario, we have a note from sales that the client is non-technical. At Quick Left, we love helping others learn about the agile process of building software. Having a non-technical client sometimes means that the initial ramp up period in the project takes a little longer, as we want to make sure that everyone is comfortable with how the process works. While it’s certainly not a risk or a red flag, it’s worth noting to sales and the developers who ultimately work on the project.
Clients don’t always give you all the details. Hidden work can be things they forgot to mention, things they didn’t know they needed, or complicated setup or coordination with an external party. In this case, I think that an administrative panel might be necessary to manage users and maybe content. This could be especially important if kittens are indeed allowed on the site. We don’t want them hiding behind their little paws over some adult-cat only content!
Other potential missing work that could be required to make this application useful include in-application notifications and email notifications.
What nouns did you come up with? Here are mine, broken into three groups:
“object” nouns: user, user profile, note, discussion thread (notes and their replies), treat (like), friend, private message, news feed, cat gif gallery, catnip points, advertisements
“integration” nouns: Google OAuth
“hidden” nouns: administrative panel, notifications
Did you pick out some nouns that I didn’t? Why did you think they were important? Reviewing your list critically can be a good way to improve at this process. Is there something that you didn’t include as a noun? That’s equally as interesting to think about. For example, I almost left “user profile” off of my list. However, I know that a user will have at least one photo, and I don’t really know what else is included in the profile. Because setting up user-uploaded assets (ruby gems, S3 buckets) does add a little complexity beyond basic form-fields, I decided the user profile was worth a full week. Maybe it won’t take a full week, but remember: it’s an estimate.
Adding up all of the above, I arrived at 14 “nouns”. How many did you come up with? What was your weighted number? Adding 30% gives me 18.2 weeks. Yowza! Does that number “feel” right? I have concerns about the news feed: I think it might take more than 1 week, but I’m not sure exactly how long.
Because this feature set feels big to me, with a lot of ambiguity, I’d provide an estimate range of 15 – 20 weeks, with a note that we could reduce it significantly. Keep reading for more on that, in the “Scope Reduction Suggestions” section.
Because I’m not a designer, I don’t try to estimate how much time they’ll need to craft the UX and make it look amazing. I put this in here mostly as a reminder to sales that they should account for extra time there.
This feature set is by no means “MVP.” This means there is a lot of wiggle room in what “needs” to be built versus what the potential client “wants” to have built. One of the beautiful things about building software using an agile process is that we can discover what is truly important, or what we really need as we go along. Because of this, I add a note with my estimate that we could significantly reduce the time/cost to build the first version of this app. The first thing I would suggest to cut is the vague “cat gif gallery” with its “catnip points”.
Because features are somewhat vague and disconnected, this project is perfect for a Quick Left Discovery Sprint. As mentioned in a previous post in this series, discovery sprints are a time at the beginning of a project when we collaborate with the client to identify and prioritize the really important aspects of their future application, and really explore what it is that our client needs and wants.
Creating estimates for potential projects can be a daunting task. Vague or incomplete information and multitudes of unknowns and variability can make it difficult to pin down a time range in which you can be confident. In this series, I’ve gone through how I complete these estimates. Hopefully, you’ve learned that it’s not all about the number. Identifying risks, hidden work, and critically evaluating the proposed project can lead to a better response for the client and a better estimate of how long the project would take.
Remember: It’s an ESTIMATE. We want to be as close as possible, but in the end, the definition of “done” for a project is a moving target.
What do you think? Do you methods of estimation I haven’t discussed in this series? I’d love to hear your ideas!