.png)
1 month ago
21 ARTICLE AD
“When can we ship this?” If this question gets your heart racing, don’t panic. There are a number of reasons why your team leader or Product Manager might ask for a time estimate — and they’re probably not trying to rush you.
Timelines and due dates are critical to all parts of a business. Sales needs to be able to tell prospects when a feature is being released, and Customer Support should be able to tell users when a bug fix is coming. While Product or Project Managers are often responsible for devising and communicating timelines to project stakeholders, they won’t have all the context necessary for estimating how long the programming portion might take.
Estimating the time (or complexity) of a coding project is notoriously tricky. Often engineers suggest simply doubling or quadrupling your estimation to approach something realistic. But when you’re just getting started, you might not have a reference point to gauge how long a project will take, so you have to make an educated guess — here’s how.
How to estimate software engineering work
There are many ways to approach estimation — some of which can even be fun (like Planning Poker and Dice Estimation). These methods tend to be more useful when you have experience of past projects to base estimates on. Here are some steps you can take to scope a project you’ve never done before. Regardless of your estimation approach, consistency is key. Stick to one method to track the accuracy of your estimates and refine them based on each project’s outcomes.
Draft a plan
Planning and estimation go hand-in-hand. You can’t provide an estimate without first thinking through the problem you need to solve and all the elements of the project. What parts of the codebase will you work with? How will other teams be affected? Are there existing solutions you can integrate? The answers to these can reveal roadblocks and alternatives. Of course, it’s impossible to predict everything, which is why another person’s input is valuable.
Ask someone else
Just talking through the request with another team member can help you process what’s needed. Find a trusted teammate or peer and work together to break down what you think you need to do to implement the request and document wherever the request is captured, like a Jira ticket or GitHub issue. Collaboration with teammates is a key interpersonal skill for developers, and documenting your thought processes in this way allows others to give more effective feedback. Afterward, your team leader can gut check your estimate and highlight any areas you may have overlooked.
Use a concrete metric
While some teams use Story Points or Complexity Points to put a value on engineering tasks, the Agile concept of Ideal Days might be a useful measure for unfamiliar tasks. How many perfect, uninterrupted days would it take you to complete a task, from start to finish? Breaking it down this way makes the estimate less abstract. Take care to communicate to stakeholders what other projects or unforeseen events could disrupt the days you dedicate to the task. You can learn more about Ideal Days in the free course Agile Project Planning.
Understand the assignment
A lot of the approaches for estimating work assume you’re working on a team. When you’re a freelancer or independent contractor, it’s on you to know all the details about the deliverable before you start thinking about completion time. For example, do you need a requirement spec, stories, or epics? That might mean reaching out to the client for additional details to ensure you’re aligned on the project scope and can provide an accurate timeline.
If your estimation efforts reveal there’s just too much to be done in the time you have, organize the requests into must-haves and nice-to-haves. In some cases, you and the client or Product Manager might be able to agree on a Minimum Viable Product (MVP) – a scoped-down version of the request that still meets minimum requirements.
7 surprising factors that affect project timelines
Timelines depend on several factors that are out of your control — here are some common gotchas you can look out for.
Time to read and think
You need to budget time to read, reflect on, and comprehend a request, and then do the same for your proposed solution. Think about everything you’ll need: Are you dependent on other teams to perform a task? Is there missing information you need filled in? All of these factors have an impact on the overall time it takes to ship something.
Dependencies on other teams
Dev work doesn’t happen in a silo. As a Front-End Engineer, for example, you might need to collaborate with the Back-End team to get help with an API to retrieve data for a front-end module. Identifying those dependencies and communicating across different engineering functions is a key part of estimation.
Also keep in mind that there are larger forces at play. The feature requests and quality-of-life improvements you’re asked to estimate might already be commitments made to customers or potential clients to secure a deal. Build your confidence navigating cross-team dependencies by taking our free course, Effective Stakeholder Communications for Technology Professionals.
Development vs. elapsed time
There are (at least) two elements to how long something takes to implement: the continuous development time you spend on it, and the end-to-end, elapsed time between someone submitting a request and the solution being released to production. Engineers rarely work on one task or ticket at a time, and instead shuffle several items (like a Product request and bug ticket) at the same time.
Context switching is inevitable, so be sure to factor it into estimation of a project. You can also improve on your own time management with our free course, Managing Your Time So It Doesn’t Manage You.
Code review and testing
Writing the code is just one piece of the puzzle — you also have to budget in time for safely merging the code. Each organization will have its own processes, which can include continuous integration and other automated checks as part of the pull request, as well as peer reviews. Then there’s deployment, the time it takes to go from your development environment to staging and then to production.
Testing is also always going to add to your timeline, whether you do it yourself or hand over to a QA team. Some seasoned developers estimate that writing unit tests effectively doubles development time (without even accounting for the time it takes to run the tests), so it’s important to clarify whether you should include time for testing in your estimates.
Release cadence
Your company’s release schedule might vary, with releases happening monthly, quarterly, or even less frequently. Just because the code is ready, doesn’t mean it will be live in production right away, so it can be helpful to reference release dates when estimating.
Debugging
An estimate should always factor in some time for debugging, because there will be bugs. With experience, you can start to plan based on past data. Maybe your team encountered 10 bugs during the last sprint, for example.
PTO and holidays
It might seem obvious, but time off and national holidays are often forgotten when planning engineering work. This is especially true when you’re working on a distributed team and have folks in different time zones around the world. There’s always going to be some handover time required when people are OOO and priorities shift, so account for that time, too. Need help communicating your schedule as a remote worker? Check out these tips for maintaining work-life boundaries while you WFH.
What happens if you go out of scope?
If you take away one thing from this article, know that your team leader is not expecting your estimates to be 100% correct. Part of learning includes making mistakes. With more experience, you’ll be able to make more accurate predictions, but even Senior Engineers encounter uncontrollable factors that impact project deadlines.
A lot of project planning and estimation methods in software development are rooted in Agile methodology, which you can learn more about in our free professional skills courses, Agile Principles and Methodologies and Agile Project Planning.
