Now that we’ve dispelled the myths of estimation and understood the underlying motivation for stories, we can focus on the details of estimating effectively and practically. The following framework has proven extremely effective in providing realistic estimates that work for both clients and developers in my experience.
The Three Pillars of Estimating Effectively
The three pillars of estimating ensure estimates are accurate, realistic, and always improving. If your team is consistently providing poor estimates then it’s likely they are not following one of these pillars.
Estimates should be Created and Verified by Developers
Do not allow estimates to come from non-technical people for technical projects. Understanding the intricacies of how a system works is crucial to providing any type of realistic estimate.
Use Competitive and Peer Analysis
Compare your estimates to similar estimates from colleagues and competing companies. Nothing will tell you better if you are in line with market expectations than comparing against competitive bids.
Use Previous Estimates as a Gauge
Keep track of your estimates over time to gauge future estimates.
Done vs Done
The gap between what a developer thinks is done and what the stakeholder thinks is done is one of the biggest sources of conflict and misunderstanding between the two. I call this the “Done vs Done” problem. When this gap is large, developers will not only underestimate how long tasks will take but turn in unsatisfactory work that does not meet the stakeholder’s expectations.
Developer Done: The story is done when they get a minimally viable working example of the feature or story.
Stakeholder Done: The story is done when the feature implemented, acceptance criteria met, edge cases addressed, error states fully handled, states when there is no data are handled, code has been reviewed, feature fully tested, approved by QA, approved by UAT, Continuous Integration passes, and the feature has been deployed and is actively used in production without bugs.
The disconnect between these two versions of “Done” can often be this large especially for developers new to estimation. Let’s look at a few of the reasons why developers will underestimate the requirements of a story so severely.
The best strategy to mitigate reason two and three is to use an estimation checklist to ensure everything is accounted for in the estimate. Pressure from stakeholders, on the other hand, can be managed by setting appropriate expectations early on in the process.
Pilots, even highly experienced pilots who have been flying the same planes for 30 years, use checklists to ensure that they have done all the pre-flight procedures because human memory is fallible and it is extremely easy to let something slip your mind. Checklists are a great way to mitigate mistakes and misses. The most effective checklist is the checklist that you create yourself because it will be personalized with concerns and aspects that affect your situation directly. This checklist should be continuously updated as you grow as a developer so that each new estimate incorporates aspects you might have missed last time around. Here is an example of where to start:
Depending on the type of work you are doing, this checklist could vary drastically but the important step is that you are adding to it as you encounter missed estimations and reflect on how you can improve. Save this in a text document or sticky note so you can always refer to it when making estimations. Shared estimation checklists between teams can be even more effective since the whole team will be on the same page and updating it as new cases are identified.
Stakeholder Expectation Setting
Stakeholders often start with unrealistic expectations because they want the project to be cheap, fast and high quality. Naturally, as the saying goes, you can only pick two of those at a time and let the third suffer. The idea that all three can be done at one time on a software project comes from stakeholders who are not familiar with software development. They might hold misconceptions, often contradictory, about what is reasonable, realistic, and practical for estimates and project timelines. Therefore, to avoid conflict upon delivery, you must help stakeholders better understand the software development process and dispel any misconceptions they might have.
Common Stakeholder Misconceptions
Contending with misconceptions like the ones above can be quite difficult, especially the ones that are self-contradicting. The point of setting expectations, and contended misconceptions, is to make sure that stakeholders are properly accounting for the reality of software development. Let’s explore these misconceptions in more depth to help you dispel these myths for stakeholders.
Building software is NOT like building a building
The construction industry spends a massive amount of time and effort planning a project. Architects, structural engineers, civil engineers, draftsmen, designers, and others put an amazing amount of work before even starting a project. Skyscrapers require detailed specifications and drawings down to the type and location of individual screws. Software development is not approached in this way in most cases. The nuts and bolts of software are left for the actual development phase because there are many unknowns like the capability of various third party packages and the errors, limitations, and roadblocks that might arise. In many cases, even business logic is left for the development phase.
Extensive planning for software is expensive, ineffective, and unneeded
Convincing stakeholders to take the planning phase of a project seriously is difficult. In many cases, you want more mockups, documentation, and specs than they have provided. The best move in this situation is to help stakeholders understand that each release will have a substantial UAT phase where the length of the UAT phase is proportional to the lack of robustness in the design phase. Presenting it as a tradeoff will force stakeholders to choose between spending more time in design/technical-discovery or more time in UAT or Beta phase. The key is to make sure the stakeholders understand and agree to this tradeoff. This sets the expectation that a lack of planning will lead to increased changes, budget, timeline, and UAT phase.
Changing code is extremely easy during development and will not affect budget and timelines
Anyone who has been on a software project for any length of time should recognize this is false. If a stakeholder expresses sentiments along these lines then you need to push back immediately and try to change their mind. Additionally, any deviation from the original plan, during the middle of the project, will almost always affect the timeline and budget. Code is less permanent than bricks, but like bricks, you cannot remove some without affecting others. Changing or removing code almost always requires refactoring, reorganizing, and rebuilding.
Continually reset expectations with new changes
Setting expectations with stakeholders does not end once the project moves into the development phase. Adjusting the estimates, timelines, budgets, and releases is essential whenever new changes or requests come down the pipeline. New changes that affect the project must be conveyed to the stakeholders on a continual basis to ensure expectations align with the reality of the project. More specifically, resetting expectations often will do three things.
One, it will ensure that the estimate is always accurate to the current requirements of the project instead of an outdated estimate you made months ago. Avoid the temptation to simply absorb the new changes and hope it all works out because this will almost always fail. Requested changes after the initial estimation will affect the timeline and outcome in most cases.
Second, it will discourage the number of changes coming in before releases. If the stakeholder is seeing how changes are affecting the budgets and timelines, they will be more inclined to push the changes out beyond the scheduled release.
The best method to continually reset expectations is to set up a weekly or biweekly meeting with stakeholders and reset expectations whenever possible.
Narrow your Estimation Scope
Breaking large problems into smaller problems is an extremely effective technique for tackling projects. The larger your estimation scope is, the lower the accuracy of the estimate. Imagine a new project will take four developers nine months to complete. This amounts to about 5,700 working hours for the development team alone. Predicting exactly how the project will unfold during those 5,700 hours is unreasonable, there are just too many variables, factors, and unknowns.
Instead, break these 9 months of work into phases and plan deliveries along the way. Perhaps this application has 4 different parts: user management, project workflow, invoicing, and reporting. Aim to release and deliver each part to stakeholders instead of the whole application at the end of the project. This gives you a release about every 2 months, which is a much more manageable amount of time to properly estimate and plan for. Breaking those two months further into four equal two-week sprints will narrow your estimate scope even further. This pattern of breaking down problems into smaller ones is fractal. The following are the common breakpoints in software development from the broadest level to the most specific. Each of these describes a different scope of work with different purposes and timeframe. You should be using all of them to properly plan out work.
A project describes the largest scope of work and often represents an entire application. The timeframe for projects is typically measured in months but can be several years.
Projects are used by the highest level stakeholders to plan and solve large problems.
Sections are large portions of an application or system that consist of numerous epics. They are usually not estimated directly or releasable on their own. Typically they simply group epics together.
A release typically represents a section of a project that makes logical sense to be released together. An example of a release would be the “reporting” section of an application or “authentication” release. Once the work is finished for the reporting section it can be grouped together and released to the stakeholders for user acceptance testing. Releases differ from projects because they usually represent a working section of an application rather than the whole project itself. Releases, as their name suggests, should be in a state that can be “released” to stakeholders. The timeframe for releases ranges pretty widely but typically these range from a few weeks to two months.
Releases are used by Product Owners and Project Managers to plan milestones, budgets, and product release schedules.
Epics typically represent a specific feature of an application. For instance, inside of an authentication release, you might have a Forgot Password epic. The whole authentication release might be made up of several epics: Signup, Signin, Logout, Forgot Password, OAuth, and SSO. Epics should generally take more than a day, but no longer than a week. Anything over forty hours should be broken down into multiple epics.
Epics are used by Project Managers and developers to ensure that they are properly planning out sprints that will lead to on-target releases and budgets.
Unlike projects, releases, and epics, sprints represent a consistent amount of time. Typically, sprints are one or two weeks. Project Managers or developers add tickets, stories, or work that will be completed during the duration of the sprint. Though every project is different, in my experience teams should complete at least one epic per sprint with each developer committing to more than ten stories.
Sprints are used by Project Managers and developers to ensure adequate efficiency and velocity. Additionally, it ensures there is a regular cadence for planning new work, executing against a deadline, and reflecting on delivery.
Stories are the smallest scope of work that can be considered complete. Sessions are smaller but are more like sprints in that they represent a fixed amount of time more than a complete scope of work. A story should represent one aspect of a feature. For example, with the Signup epic, you could have a story: “A user will see the validation errors when missing information on the form”, which could represent 6 hours of work. The timescale for stories is usually measured in hours and shouldn’t exceed 8 hours.
Stories are mainly used by developers to plan, estimate, and deliver sprints and epics.
Sessions represent the amount of time that a developer will sit down and focus on a given story or issue. Generally, this is about 3 hours and is the smallest amount of time a developer should plan for. Each day, developers should plan out their sessions according to what needs to be accomplished. For example:
Session 1 - (3 hours) Finish API endpoints for forgot password
Session 2 - (3 hours) Finish UI for forgot password form and tie state management and from submission to API.
Each layer of planning builds on the layer below. Breaking large problems down into smaller and smaller goals is essential for achieving large goals. For each smaller goal: plan, estimate, and execute each so they add up to efficient, well planned, visible, executed work that stakeholders can be happy with.
Plan for the unexpected
Although you can mitigate the effects of unexpected events by creating and maintaining your estimation checklist, you can never avoid unexpected events or results. Therefore, instead of agonizing over when the unexpected will come, incorporate the unexpected into your estimation so you can more easily handle the situation when it does come. All projects will typically encounter two types of unexpected issues: small and large.
Almost all stories include at least some unknowns unless the task is trivial. Stakeholders plan their goals around your team’s development velocity. Unknowns, even small ones can affect velocity, therefore it is important to always inform stakeholders of all unknowns on a frequent basis. Following the estimation process rigorously each time you estimate should help produce a consistent amount of unknowns that you can plan for.
Large unknowns will pop up periodically, usually at least one per project. The best way to mitigate a large unknown is to include a buffer in your estimate that your team can use when a feature starts to go south. Another powerful way to plan for large unkowns is to build up trust captial with stakeholders.
One way to conceptualize your relationship with your client is in the form of trust capital. There are two main ways to build trust capital: turn in high-quality work or deliver on time and on budget. Since this series is about estimation and delivery we will focus on the second method of building trust capital. Every time you deliver something for a client on time or on budget, you build up a reserve of trust capital. This capital can be spent to smooth over problems or mistakes in the future. For example, if you have built up a large store of trust, the client will be more forgiving and lenient when something goes wrong on the project. They will trust that you were doing your best to deliver the feature rather than assuming you’re doing a poor job. However, if you miss estimate after estimate, egregiously going over your estimates, you will eventually spend all of your trust capital and the client will end up firing you or dropping the contract. This is why it’s important to get estimation right, you get more leeway to handle large unknowns or unexpected problems down the road.
You understand the problem, you have the toolset to break the problem down into smaller problems, now is the time to provide a real estimate. Once design and technical discovery are completely done, start to break down the project into epics for each section of the application. However, do not estimate the epics directly. Later on, you will estimate the individual stories and add up each story estimate into a full epic estimate. A typical estimate list might look like this:
Once you have all of your epics listed out, now it is time to go through each and create the stories for each epic. For example:
Now that we have five or so stories for the first epic, let’s walk through how we would estimate an individual story.
Using the Checklist to estimate a story
We will use the first story, API can accept signup form submission and persist User in Database, to illustrate the questions, answers, and thinking that goes into estimating a story.
Does this change affect the UI?
No, this story is only describing the API side.
Does this change affect the API? Have you considered schema changes, migrations, models, controllers, routes, resolvers, endpoints, scoping, relationships, background jobs?
Yes, we do need to account for schema changes, migrations, models, controllers, routes, endpoints, scoping and relationships.
Have you allocated time for robust test coverage?
Have you allocated time for code review, final review and revisions?
Have you considered what refactoring of the current codebase is needed?
Yes, we do need to account for these in this case.
What libraries are needed by this ticket? Are they included yet in the project? Have you worked with them before?
We will need to include an authentication library as well as an encryption library for password storage and I have used them before.
What data is needed for this ticket?
This is a new application so no data is required outside of the seed data that is already there.
Have you accounted for SEO requirements?
There are no SEO requirements for this task.
Have you accounted for security requirements?
Yes, we will include an encryption algorithm for password data and enforce HTTPS to ensure encryption when in-flight.
What internationalization requirements exist for the ticket?
There is no i18n on this ticket.
What risks can you see by looking at the ticket as it's written? Is there anything that you need to do now to mitigate against these? Does this story need a “Spec Story” to further define any of its parts prior to estimating?
There are no obvious risks here and everything described here is standard authentication.
Estimating a Story
Always give a high and a low estimate for each story. An estimate range will help you convey timelines better by highlighting stories that contain many unknowns. For the story above we might estimate 3 hours on the low end and 7 hours on the high end, which means 5 hours should be your target to get this story through QA and into UAT.
Continue this process with the remaining stories until you have estimated each story within the Auth Signup epic. Once all stories are estimated, sum up the total number of hours and use that total as the estimate for the full epic. For example:
Estimating an Epic
Summing up all the stories for the Auth Signup epic amounts to 16 hours. If 16 hours of development sounds reasonable for the given epic, then the only left to add is the buffer for unaccounted parts of development like project management, communication, and quality assurance. Although this will vary project by project, a good idea is to start with around 10% additional time for each of these (10% * 16h).
|Dev time -||16h (low: 10h, high: 23h)|
|Total -||~21h (low: 13h, high: 30h)|
This whole package is what you will turn into your stakeholders. A range of 13-30 hours or in working days about 1.5 - 3.5 days with a target of 2.5 days. Remember that 2.5 days is including all of the effort put into getting this into production (PM, comm, QA, dev time, revisions, deployments, etc).
Sending this package sets the expectation for the acceptable range in which to finish the assigned work. However, if you always finish above your average across all of your stories and epics or you will drastically blow your overall budget and timeline. Most of the time you should be hitting close to the average estimate, other times you will come under estimate. Averaging out over the course of the project should allow for the buffer to weather situations where you need to go over the average estimate.
Verifying your Estimate
During development, you will often receive an estimate that was not created by you or meant for another developer of differing skills and knowledge. This is the perfect opportunity to use teammates to verify the estimate given. Make sure time is allocated during sprint planning for developers to check if the estimates on their tickets are reasonable and identify any problems that might impede their commitment to the estimate. This is important because all estimates should be signed off on by the engineer that is actually working the story.
Now that we’ve learned how to estimate effectively, we can move on to the next part of this series: Developing Against Estimates.
At FullStack Labs, we pride ourselves on our ability to push the capabilities of cutting-edge frameworks like React. Interested in learning more about speeding up development time on your next project? Contact us.
We’d love to learn more about your project. Contact us below for a free consultation with our CEO.
Projects start at $50,000.
An interpreted high-level programming language great for general purpose programming.
A server side programming language known for its ease of use and speed of development.
View a sampling of our work implemented using a variety of our favorite technologies.
View projects implemented using this high-level programming language great for general purpose programming.
View projects implemented using this framework that allows rapid development of native Android and IOS apps.
View projects implemented using this server side programming language known for its ease of use and speed of development.
Learn more about our current job openings and benefits of working at FSL.
Detailed reviews and feedback from past and current clients.
Detailed profiles for each member of our team.
Our step-by-step process for designing and developing new applications.
Get answers to the questions most frequently asked by new clients.
Learn more about FullStack Lab’s Mission, Vision, & Company Values.
A high level overview of FullStack Labs, who we are, and what we do.