How to Estimate and Deliver Software Projects (Part 4)

Working Against Estimates

Written by Mike Piccolo, CTO

At this point, all epics and stories have been estimated and presented to stakeholders for approval. If stakeholders agree to the timelines and budgets proposed, then it’s time to commit to working against the estimates you provided in an effective, productive, and organized way.

How to approach your estimate

Some developers will jump right into working on the work assigned without thinking about how to approach their estimated work to finish it on time. Naturally, this is not a recipe for success. In the first article of this series, we discussed how important mindset is for the ability to deliver consistently on your estimates. Mindset is still extremely important, but it isn’t quite enough. To really succeed in hitting your estimates, you need to commit to the estimate.

Committing to the estimate

In the book, Willpower Doesn’t Work: Discover The Hidden Keys To Success, Benjamin Hardy argues that when you make a decision and commit to it, it becomes part of your identity and removes any issues you concerning your willpower.

“If you haven't made a decision yet, then you're going to be required to use willpower.”

As much as possible you need to become the type of person who delivers on what they commit. Who you identify as a person should be someone who estimates effectively and delivers on those estimates consistently. Identifying as this type of person, as a core part of who you are, removes willpower from the whole equation. Questions like “should I go grab a snack or procrastinate” will no longer be a problem when your identity is tied to staying productive and delivering on your commitment.

Some developers approach their estimated work wishfully believing they can finish their work within their estimate without planning anything or reflecting on previous mistakes. They do not plan to hit the estimate, they make no pragmatic decisions along the way, and they do not reflect on why estimates were missed. In short, they are not committed to hitting the estimate provided, they are simply blindly wishing that everything will work out in the end. Developers who approach work this way rarely grow or improve their ability to hit estimates, instead, they keep making the same mistakes over and over. The value they provide for their teams can be offset by the wasted time spent creating and tracking an estimate that they ignored during actual development. Rather than being wishful, we should be committed to hitting our estimates and becoming the type of person who can commit.

Practical steps for approaching estimates

1. Plan early and thoroughly.

  • Ask what steps are required to deliver this feature on time?
  • What tradeoffs will need to be made?
  • What pragmatic decisions can you make upfront?
  • Do you need to hold off on a large refactoring until the next sprint?

2. Timebox your work.

If you have an 8-hour task and you know that you need to finish the API side in 3 hours, give yourself a timebox from the start of the day to lunchtime to finish it completely. Mentally preparing for working a large chunk of work is a big step to actually getting it done. Additionally, this will help with the urge to multitask or do things that are off task.

3. Make pragmatic decisions.

Oftentimes during large projects, you will feel the need to allocate time for major refactors, or adding additional test coverage, or open sourcing a module you’ve been waiting to do for a long time. While all of these can be quite beneficial and worthy of our time, we need to stay pragmatic and weigh the relative importance of tasks against getting the whole project finished. Plan to make pragmatic decisions to ensure you get the work done on time and on budget while still providing the expected quality.

4. Reevaluate as deadlines approach.

Constantly reevaluate where your team is at on the timeline and how well your team is doing to meet the estimate and budget. Every time you take a break and return to your work is a perfect time to accomplish this. Ask yourself:

  • Are there any pragmatic decisions that need to be made based on the status?
  • Should expectations be reset with the PM and stakeholders due to new information?

These are broad questions that affect the project as a whole, but we also need to reevaluate the granular aspects of each story and epic. Follow the next three steps to make sure you are still on track.

  1. Ensure you are aware of the estimates at all times: You should be able to answer the question: "How much time do you have left for the story/epic?" at all times.
  2. Write out your plan every day including the estimates: Every day write down the estimated time remaining on the stories and epics you are working on. If the time remaining is less than the time that you think you will need to finish, it should be listed as a concern and discussed with the Project Manager or stakeholder.
  3. Reevaluate the plan vs estimate for every ticket: Every time you return to work on a ticket, you should know how much time you have remaining. At this point, you need to ask the question: "How can I complete the task with the remaining time and what pragmatic decisions need to be made to achieve this?".

Pragmatic Decisions

Pragmatism: Dealing with problems realistically, based on practical rather than theoretical considerations

Idealism: Unrealistically aiming for perfection

Understanding the concepts of pragmatism and idealism will help you on a day to day basis with your work. Pragmatism will mean different things in practice because stakeholders usually have unique goals and every project is different. Unfortunately, this means there is no magic formula or checklist to follow to always make pragmatic decisions. However, one of the best ways to understand pragmatism is to see it in action with a few examples.

Testing Pragmatism

Let's say you are working on a project that has 70% test coverage but the stakeholders indicate they want to get it to 90%. In this scenario, you might be the testing advocate on the team who just so happens to be working on an epic that touches most of the application. A naive developer might get overly excited at this point and start increasing test coverage right away on the epic they’re working on. But pragmatic decisions require us to take a step back and ask the question: “Is increasing the test coverage right now during this task the pragmatic decision?” We can better answer this question by asking some more specific, related questions.

1. How much more time will be added to the sprint by trying to increase the coverage 20% for this epic?

If you incorporate the increased test coverage while you work through your stories, it might take an extra 4 days for you to increase the coverage

2. Will this push out a release?

Most likely it will push the finalization of this epic into the next sprint with these 4 extra days.

3. How important is this epic for the current release?

In this scenario, perhaps the stakeholders are expecting to demo the project and new features to the C-level execs after the completion of this epic, in which case this epic is extremely important for your team.

4. How beneficial is it to increase the test coverage now versus retroactively next sprint?

Given the stakeholder's goals, it is probably more beneficial to wait until after this epic is done to start working on test coverage.

As you can see in this example, the pragmatic decision is to hold off reaching 90% coverage during this epic. That doesn’t mean you should totally ignore testing in this epic, but you should focus on delivering the vital features of the application for the stakeholder demo.

The pragmatic decision in this scenario was to hold off on adding additional test coverage, but that doesn’t mean that this will always be the right decision. The exact same scenario could lead you to the opposite conclusion given what you know about the stakeholders and the specific project expectations. For example, if the stakeholders didn’t have a demo the cost of pushing the epic out farther would be much less detrimental. Another possibility is that the team is expecting to onboard a bunch of new junior developers on the project who would greatly benefit from the increased coverage. In this situation, you could easily see how the pragmatic decision could be to focus on the test coverage instead of finishing the epic.

Refactoring Pragmatism

In this scenario, the project has a very large and complex file that needs to be refactored. Reducing the complexity of this file will undoubtedly result in a better experience for everyone. But, as with the previous example, we need to ask ourselves a few questions to flesh out whether this is a pragmatic decision to make. Below are a few questions you might ask yourself when evaluating this problem.

  1. How often is this file touched by developers and how often do you believe it will be touched in the future?
  2. What is the actual complexity using Cyclomatic Complexity checks? How does this compare to the rest of your codebase?
  3. How much time do you estimate you will need for this refactor?
  4. What tasks are you not doing in favor of this refactor? Are there any higher priorities?

The answer to these questions will lead us to make more informed and pragmatic decisions. Depending on the answers, the decision to refactor could go either way.

QA Pragmatism

Some QA professionals have a tendency to return tickets with rejections and comments that are better described as opinions rather than objective misses on acceptance criteria. This is a perfect time to evaluate whether addressing QA’s concerns is pragmatic or idealistic. Ask yourself whether you should handle the changes during the story you are working on or create a new story for the next sprint. Some questions you might ask yourself in making this decision are as follows:

  1. How severe is the defect?
  2. How long will it take to fix the defect?
  3. Will fixing it affect the delivery of the sprint or affect the release?

Think through these questions in different scenarios and consider what answers here would push you one way or the other?

What happens when you cut something for pragmatic reasons?

Sometimes pragmatism will lead us to defer new work until later. In these cases, you must ensure that whatever was cut ends up in a story and is prioritized later in the project. The best time to do this is directly after you have made the decision. Finally, always make sure the stakeholders are aware of the deferment or tradeoff you made.

Always timebox open-ended tasks

Open-ended tasks like “Research Stripe recurring payments API” should always be timeboxed, otherwise, you will end up spending way more time than is needed. Choose a specific amount of time, like 1 or 6 hours, and present your estimate to the PM and stakeholders. Not timeboxing open-ended tasks almost always leads to disagreements.


Using a start and stop timer is crucial for getting real data on how long tasks actually take. Get into the habit of starting and stopping your timer every time you begin and end your work because adding records at the end of the day for work done during the morning will rarely be accurate. Additionally, make sure any project management tool you use has the ability to track time spent back to stories that you are working on as well as roll up the total time into epics and projects.


For there to be any value in this whole process, you need to measure your work and track it back to stories and epics. This is a crucial step that many individuals, teams, and organizations ignore. Typically, the time entries from the time tracking app you are using (like Toggl) should be added as work logs to the tickets in the application you are using for project management. At FullStack Labs, we use a combination of Toggl and Jira, where Toggl entries are sent to Jira and logged directly on each ticket. We are then able to see where we are on any given story, epic or sprint. Every day you should check the status of your stories, epics, and sprints to stay on track and adjust expectations early. If a pragmatic decision needs to be made, the earlier the better.

When estimates go over

Your estimates will improve dramatically over time by following this framework and deliberately practicing the steps required. Inevitably, however, some stories will end up going far beyond their estimate. Your goal, in these situations, is to find the root cause of the issue. For example maybe one of the following is true:

  1. You made a mistake on the estimate
  2. You made a mistake on your plan
  3. You did not execute efficiently
  4. Something truly unpredictable happened (rare)

In scenarios 1-3, let the estimate run over. After completing the story, retrospectively identify any opportunities for improvements or take-aways that you can incorporate for future stories. For example, consider taking notes for why certain stories went way over your estimate and review these notes later on.

When something truly unexpected happens the only takeaway is to figure out how often these unexpected events might occur and plan for the unexpected whenever possible. We all know that it occurs on every project so over time, if you track closely and can compare projects you can start to see patterns for how much unexpected work comes in for a given stakeholder.

Review and Adjust

At the end of each sprint, review the estimates versus the actual logged time per story, especially for stories that went way over or way under the estimate. Ask the following questions to really dig into what could be improved for the sprint.

  1. What adjustments should you make in the future?
  2. Were your estimates too low because you didn’t account for something?
  3. Were your estimates too high and need to be adjusted down in the future?
  4. Did you identify any places where you were inefficient?
  5. Did you start on some stories before they were fully specced out and ready to work?

These questions should be asked after each sprint, after each epic, and after each release.


If you’ve been following along so far, you now have a framework that you can track and measure progress. Although the road forward can be challenging and without end, you now can approach estimation with the same rigor that you would any other skill. Understand, plan, estimate, commit, track, deliver, review and adjust and repeat. Good luck!

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.

Let’s Talk!

We’d love to learn more about your project. Contact us below for a free consultation with our CEO.
Projects start at $50,000.

FullStack Labs
This field is required
This field is required
Type of project
Reason for contact:
How did you hear about us? This field is required