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.
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:
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.
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.
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.
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.
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.
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:
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:
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.
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.
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.