Use data-driven estimations to predict project timelines

Estimated reading time: 16 minutes

Being able to predict how long a project will last unlocks potential for you and your team.

Estimating timelines for engineering work is one of the most challenging parts of managing an engineering team; unfortunately, it is also one of the most crucial. Many organizations and leaders approach estimation in varying, unplanned ways, often chalking up decisions to gut feelings rather than specific data. 

A lack of information-based decision-making breeds inaccurate timelines. This triggers a domino effect of frustration from product teams/customers, which creates a lack of confidence in engineering teams. But the good news is that there is a better way! The even better news is that this method is achievable with data you already have access to if your team uses Jira or a similar platform to track engineering work. 

Understanding your data

Examining the what, why, and how of tracking this data is at the crux of it all. Knowing what to track, how to communicate the process, and then how to set up tracking lays the groundwork for a positive experience for you, your engineers, and your product team.

What?

The first step is to understand what we will be tracking. We are looking at two major streams of data: individual engineer ticket completion rate (combined to give the total team completion rate) and project size broken down by tickets and/or points. Ticket completion rate, while it by no means paints the full picture of an engineering team’s accomplishments or an individual’s contributions, does give a great overall idea of a team’s velocity; combining this information with a given project’s ticket count is what allows us to make data-driven timeline estimates. 

Why?

It’s important to clarify the purpose of this data tracking right away, both what it is and, just as importantly, what it isn’t. This helps keep everyone – you, your leadership team, and your engineers – aligned with what this data can and should be used for and avoid misusing it as a catch-all metric for engineer productivity.

• What it is: a way to gather data better to understand a team’s ticket productivity/completion rate.
• What it isn’t: a way to micromanage engineer work and create quotas that become a source of engineer anxiety.

This second point is critical. You may need to reaffirm to the engineers on your team and emphasize to your leadership team, in multiple settings (stand-ups, 1:1s, retros), that the aim isn’t to micromanage ticket velocity and that you understand the story of someone’s productivity isn’t told solely through ticket work. However, you should outline that ticket work is a good measure of what a team can accomplish in a sprint and, therefore, a good way to predict timelines. 

Gathering the right data 

Having established what information we need and why we need it, now it’s time to obtain it. You can go about tracking data in many ways, but the below method requires Jira integration specifically: 

To get the right documents for tracking, download the Google Sheets Jira integration. The link provides easy installation instructions.

1. Import engineer velocity data and measure over time. I like to reference the most recent 12 weeks (six sprints), which provides a good average view of performance/velocity. It also allows for variations like paid time off (PTO), holidays, code freezes, etc. Create a tracking sheet with a tab for each of your engineers and pull in the data from Jira for that given period using the “issues” tab on the Jira extension.
2. Exactly how you pull in the data is up to you, as the Jira Sheets integration gives you multiple options, but I like to use this query:
   
   Status = Done
   AND resolved >= -12w
   AND assignee = [Name]
   ORDER BY resolved DESC, updated DESC
   
   This gives you the last 12 weeks of completed tickets for a given engineer, ordered by completion date. You’ll also want to set up automatic data refreshes to keep this information up to date, which you can do in the “schedule” tab of the Jira extension. 
3. Once you have the data for each individual engineer, you can compile them into one sheet.  The table will vary depending on your needs, but I organize my team’s data in the following way:

4. Now that you’ve got your team’s data imported and broken down, it’s time to create a separate sheet to track your project. Using Jira, pull in project-specific data. The setup will vary depending on how your team creates/tracks projects, but a simple query like this imports all tickets from a specified epic and sorts them by status:

• Parent = [project name] 
• ORDER BY resolved ASC, status DESC

---

London • June 16 & 17, 2025

Speakers Gergely Orosz, Camille Fournier and Lara Hogan confirmed.

See who else is speaking

How to turn your data into actionable progress 

By now, you should have a lot of data that you can use to estimate how long a given project will take. Here is the equation I like to use to calculate overall project time: 

Project ticket count (and/or points) ÷ by combined engineer velocity = project length

You can choose to further break this down by front-end/back-end work, individual engineers assigned to a project, or whatever will give you the most accurate projection. Whichever you pursue, the same basic equation applies: you are looking at the number of tickets in a given project divided by the combined velocity of the engineers working on that project. Once you’ve come up with your initial timeline estimate, I recommend padding in some extra time for unexpected roadblocks, additional tickets, etc.

Depending on how your team does project planning, you may need to make some changes or improvements to the process for this estimation to be possible/effective. For example, on my teams, we create all tickets as early as possible in the project planning process and attempt to assign point values to each ticket well before work begins. This helps streamline planning and improve the accuracy of the timeline.

I’ve implemented this timeline estimation process across several projects over the past year. In each case, the predicted timelines were accurate to within one sprint. As a result, this timeline estimation is now something that my engineers, product managers, and director rely on for roadmap and capacity planning.  

Final thoughts

Implementing this tracking and estimation process has provided me with several positive outcomes: 

• A way to measure and track the work that my engineering teams do and ensure it aligns with the right goals.
• A data-driven method for project timeline estimation.
• A way to build confidence in engineering teams among our product/design teams and other stakeholders.

I hope that other engineering leaders now feel empowered to do the same.