Written By: Steve Zagieboylo, Senior Architect at Calavista
Calavista boasts an impressive 90+% on-time, in-budget track record. As I pointed out in an earlier blog, I consider this SEVEN times better than the industry average of 30%. And yet, Calavista is very firmly an agile shop — we know the folly of waterfall methodology, especially for greenfield projects. It doesn’t really work for real projects that real people care about, because a lot of the decisions you make in designing software can’t really be made without putting it in front of real users. Many people will claim that you can’t really do accurate estimations in an agile environment, because you can’t estimate if you don’t know the final target, but those people are wrong.
Lawrence Waugh (CEO and Founder of Calavista) likes to compare the process to house construction. Let’s say you have purchased some land, and you want to build a house. You go to an experienced house builder and you say you want a 3-bedroom colonial with 2.5 bathrooms, and you want to know how much it will cost. After looking at the lot and asking you a few questions — room sizes, dining room, quality of furnishings and finish — he will give you a number. It will be a suspiciously round number, but once you work out all the details, it will turn out to be pretty darn close. The contractor can do this because he has done it a lot of times before, and he knows the sort of basic costs and the sorts of problems that can crop up, and he makes an allowance for a reasonable number of them. In other words, he has built houses much like the one you want to build, and he knows what the process is going to be.
Software is similar, though there is a much wider range of targets than in house building. Since starting at Calavista, I’ve worked on a project that was done in 4 months with a team of 5 people, and I’ve worked on a project that was 18 months reaching MVP (and continued from there) and peaked at 35 people. So how do we estimate such a wide variety of projects?
Understand the Goals and the Scope
When we are making an estimate for a new piece of software, of course, the first step is to understand what it is supposed to accomplish. This is different from “what it is supposed to do.” The latter question leads down a dangerous path which ends in waterfall specs. We are not, yet, trying to document user flow or data models, we are just trying to capture the basics of who the users are and why they will be using the software. Who the users are might be equivalent to roles, — it certainly should include all the roles — but might have a few more. The “accomplishment” level of specificity is closer to “Manage the list of items in the store” rather than the specifics of adding/removing items, changing the prices, etc. This is the equivalent of learning that the house is to have 3 bedrooms or 5.
List Major Areas of Activity
For each role, list the things that they want to get done using the software. This is a subset of the stories you will end up with, it is just the important ones, the happy path. A complete set of stories includes all the odd cases — e.g. users wanting to back up and start over in a process — but I’m not going to get to that level of detail in making an estimate. I know from the dozens (hundreds?) of times that I have created user flows, that these extra stories will always be there, and my experience in creating includes those, so my estimate will, as well. This is the equivalent of learning that there will be 2.5 bathrooms, a large dining room, and a swimming pool.
Sketch Out the Data Model
Your mileage may vary on this step, but I continue to be a “Data First” architect — that’s just how I think. I make a simplified Entity Relationship Diagram (ERD), not a full-blown database diagram, and I don’t imagine that it is 100% accurate, or even 60%, but it leaves me in a state of stress if I don’t at least scribble this down on paper. If I can feel the shape of the data as it fills and flows, that helps me complete the next step.
List Out All the Screens
Next I write down all the screens that the app will present. In modern Single Page Apps or hybrids where a lot happens on a single page, this is not as clear as it used to be, but it works just as well to think of it as a multi-page app with relatively little reuse of screen real estate on a page.. The app hasn’t actually been designed, yet, so I’m not really talking about literal screens that will be presented to a user, necessarily. It’s really just the functionality of user interaction, and these pieces might go together very differently but will still end up having all the parts I’m considering.
A UI-centric architect might do this before the previous step, and be perfectly successful doing it; it’s a matter of preference.
For each screen, I enter three values, Back end cost (in person-days), Front end cost (also in person-days), and a fudge factor which ranges from 2 to 10. Having lots of fields and a complicated layout increases the front end costs. Having both data to be fetched and data to be saved increases the back end cost, plus the complexity of the data needed and saved increases it. (This is where my data model helps.) I don’t get down to the individual field level, but I try to be aware of ‘tricky’ fields, such as a field that will have to include a type-ahead against data that is filtered by selections in other fields.
The fudge factor is usually around 4, but these things increase it
- This part of the data model is not that well understood, so I expect changes.
- This part of the user interaction is not that well understood.
- There’s a ‘science project’ involved, such as interaction with some outside library that I’ve never used before.
- There is workflow. It’s always harder than you think.
- There is more than one sub-table involved, where list management is needed at multiple levels. For example, Customers have Orders and Orders have Items Ordered and Items have Features (size, color, quantity, etc.)
- There is user input we can’t completely control, such as an upload of a spreadsheet for batch processing. Users have an amazing ability to mess these things up in unexpected ways.
To continue the analogy to house building, we’ve now specified the sizes of the rooms (more or less), the size of the pool, the length of the driveway, and the quality of the appliances. We are not going to get any closer than this in the estimation level. Once we actually start the project, that’s when we’ll do the equivalent of hiring the architect and putting together the completed plans, including all the details — closets, plumbing, vents, etc.
Add Non-Interaction Features
I add these in the same list, but they have a 0 for the Front End cost. These are things like emails that get sent, background tasks that perform data maintenance, batch processing tasks, data migration from an earlier version of the product, etc. Data Migration, by the way, is always way harder than you think, just go ahead and double it, AND add a large fudge factor.
This is also the step where I think hard about the non-functional requirements, such as performance, security models, time zone issues. If any of these are outside the bounds of the normal stuff I’ve done several times, I’ll add extra tasks to cover them. I don’t mean to imply that they are necessarily small afterthoughts just because they come at the end. Many of these are pretty significant tasks, possibly even being a proportional overlay to the existing work, such as multi-tenancy, which more or less doubles all the back end costs.
Apply the Formula
My formula for the actual costs is:
(base cost) * (1.25 + (fudge factor)/5)
The result is that each task with a fudge factor of 4 gets approximately doubled, and higher or lower fudge factors are a little more or less than doubled. This is what I’ve found, just from experience, that the time I expect a task to take needs to be doubled to cover actually completing the task, with completed unit tests, responses to code reviews, and getting it merged into the Development branch. The 1.25 is a factor to account for developers spending time in meetings, as well as time lost to vacations, holidays, and sick time.
Estimate Personnel vs. Time
Next, we make one or more plans with people and deadlines, such as “4 back end, 3 front end for 8 months,” taking the requests of the customer into consideration. If they are looking to meet a hard deadline, then we figure out the number of front end and back end engineers we will need to get all the work done before the deadline. If they have been less specific, we might put together a few scenarios with different team sizes and different target dates.
Add the Other Parts
After that, we add QA, Requirements Analyst(s), UI/UX, DevOps, and the time for Calavista Solution Director and Architect who together will shepherd the project. We usually also include a “Sprint Zero” for kicking off the project, getting source control, Jira, Confluence, Communications, and the rest of the development infrastructure into place. Some of these are proportional to the amount of work, some are fixed costs.
Make a Proposal
Finally, we bring this all together into a proposal. We know that if we get the contract, we will have a framework and enough time to create something that will accomplish the customer’s goals. There will be changes, of course, to the different pieces: the pages, the layouts, the secondary goals and tasks, and the delivery; but with this process we have been very successful in delivering software that makes our customers successful, within the time we’ve actually predicted, which is our ultimate goal.
