Before you write any code on a project, you will estimate how long it will take you to do so. A good estimate of development time will lead to an accurate schedule and budget, plus happy developers, POs, account managers, and clients. A bad estimate might lead to missed deadlines, going over budgets, and pain that could have been avoided.
Developer estimates are problematic when they are either too low or too high. Low estimates cause stress for developers as they struggle to stay on an unrealistic timeline. Low estimates also result in going over budget and missing deadlines. High estimates, on the other hand, can result in difficult conversations about timelines with clients, high bids that lose business, and over-staffing.
Everyone misestimates sometimes. Learn from every inaccurate estimate, and over time you will become a better estimator. Bring up your significantly inaccurate estimates in your sprint retros and talk through how you can improve next week.
Raise Constructive Concern Early & Often
When creating or reviewing estimates make sure to raise any constructive concern as early and as often as you are able. Even mid-sprint, if you feel that an estimate is inaccurate or that the feature it describes does not meet the needs of the product and stakeholders, bring it up at the next stand-up.
This helps the entire team continue working towards the larger goal of sprint completion, while providing the PO/AM team with the necessary information to inform the client of the new options and expectations. Try to state the concern along with a few potential solutions to the problem, allowing the team to move forward - actionable concerns are the most valuable.
Nonconstructive: There is no way I will complete story X by this sprint.
Constructive: I will only be able to complete my tasks if we breakout item X into two different stories or implement it in this new and/or innovative way.
Types of Estimates
There are several types of estimates used at Vokal that serve different purposes and require a different degree of assumptions to be made. During each step, stories will be more specific, and estimates will be refined to be more accurate. Each step is also an opportunity to reconsider the project plan and confirm that it is still meeting the needs of all the stakeholders.
Business Development (Initial Estimation)
Prior to discover, estimates are needed in hours in order to establish client budgets and schedule teams. Because these estimates are made with the least amount of information, it is particularly important to record the assumptions and scope of the features being estimated.
Creating a Backlog (Detailed Estimation)
The story backlog, maintained in Jira, is estimated using a Fibonacci point sequence which relates to hours. An ideal backlog contains a complete roadmap for building the project.
We use Fibonacci numbers to estimate because the larger the story, the less likely you are to estimate it accurately. You're safer picking a Fibonacci number for a reasonably large feature than trying to peg the exact number of hours. This gives us a "t-shirt size" (Small, Medium, Large, XL) estimate of larger stories.
These placeholder stories may have higher point estimates than are encouraged during Sprint Planning, when you'll be asked to break things down into smaller pieces.
Sprint Planning (Estimate Refinement)
Estimates from backlog creation and grooming should be further refined during sprint planning. During sprint planning each story should have a highly granular list of tasks added and a final more accurate point estimate should be assigned to each story. During sprint planning or backlog grooming, stories may be divided into smaller stories to create a more granular set of deliverables.
Tips for providing more accurate estimates
Have a Definition of Done
All estimates need to account for the total amount of work that is required but not explicitly stated. To do so, each project needs to have a formal Definition of Done. These vary based on the project and team structure, but this is an example:
- Features have received sign-off from the Product Owner
- Features have received sign-off from the Design Team
- Features have automated unit tests with 100% coverage
- All automated tests are passing
- Code is factored and documented to standards
- Design artifacts have received sign-off from the Dev Team
Be mindful to adjust estimates to include time to complete all stories based on the Definition of Done.
Know the Odds
An estimate should never be based on the fastest or slowest time you think you can complete a task. An estimate should be somewhere between the best case and worst case. A good estimate is the amount of time at which you think there is a 50% chance that you will have completed the task.
For example, ideally you'll finish a task in 3 hours, but there is some unknown that has a chance of adding a few hours to your estimate. Since you can't be sure if it will be an issue, you include some time for the risk factor and decide there is a 50% chance you'll be done in four hours. Your estimates will vary based on how likely you think risk factors are and how much time each will add.
The larger the task being estimated is, the more likely you are to overlook requirements. As a task gets larger, it will become more difficult in a non-linear way. Break tasks down into smaller pieces you can estimate more accurately, or add time to your estimate to cover unknowns. Story estimates will be more accurate when tasks are added to those stories in Jira.
Dates and Times
Features that involve working with dates and times are often drastically underestimated and underscoped. When creating a feature list consider time a number of states that are each separate features. States can include past, present, future, standard time, daylight savings time, timezone transitions, date conversions and other time calculations that behave differently depending on the time of the year. You don't want to end up like this guy.
Unclear requirements lead to rework and extra time to conceptualize a feature. Before starting on any feature, understand what other team members think the feature is. If you are creating a long-term project schedule, these unclear tasks may justify adding time for these unknowns, particularly because unknowns compound changes over time.
A Good Backlog
Your project backlog must be in a state where you have confidence that you can meet long-term project deadlines. For example, you may have a backlog that is not organized, and makes long-term estimates impossible; or you might see that you have 4 weeks to do 6 weeks worth or work. If any situation arises where you are not sure if you can complete the project on time, say something to your PO immediately. The PO should give you guidance on organizing the backlog, adjust project staffing, or work to adjust client expectations.
If you are not sure how many points to make a story, you should round up to the next number. There will always be unknown things that crop up on those tasks or other tasks you thought would be simple. Underestimates tend to balance out better when you just round up.
Don't be a Hero
You should not routinely be committing to more than 40 hours of work in a week. On most projects, it is more effective to commit to 30 hours of work. This way you can regularly complete all committed tasks and are not idle at the end of a sprint. If you are regularly working more than 40 hours a week or missing sprint goals, adjust your estimates, talk to a senior engineer for estimating advice, or talk to a PO about your project deadlines.
Estimate With Your Team
It is important to validate your estimates with the designers and POs on your project as they will both validate your assumptions and have insights into the purpose of a feature that you have overlooked.
Make & Record Assumptions
If you had to wait until everything was fully defined, we would never build anything. A huge part of estimation is making assumptions - on everything from authentication methods, functionality, button states, even application flow and designs. It’s uncomfortable, but in order to move forward with a project, assumptions must be made. Be sure to think about, voice, and document the assumptions you made when coming up with your estimate. This helps everyone involved in the production process. You will have documented your mindset and thoughts at the time of estimation, others will comprehend the same assumptions, and the POs will have a better sense around what can influence your estimates.