This post is part of a series where we document our journey of building a new product, 7pace For GitHub in real-time. We share our experience and what we have learned along the way. Here’s how it all started.

Estimating how much time you need to work on an entirely new product can be challenging. You don’t have any precedent to reference, so how can you estimate the time and effort required to complete each task and determine a reasonable timeline for the project?

Timeline estimation is one of the initial challenges we faced as we embarked on the journey to develop 7pace for GitHub. (If you haven’t already, sign up to read new posts and teardowns of our product development process.)

Let’s take a deep dive to see how our team approached this tricky issue.

Know Thyself: A Solid Foundation To Work From

Since we’d leverage what we already know to help us navigate the unknown, let’s start with how we typically estimate and plan a project.

Our team has been using 7pace Timetracker in Azure DevOps to record our time, which gives us insights to improve productivity and create accurate estimates as individual developers and a team.

We have also developed a KPI called “pace” to measure the relationship between tracked time and estimated efforts (i.e., story points.) Pace is calculated by dividing time tracked in a previous task with the number of story points of that task.

Since we know the pace of each development team, we can develop an accurate estimate of our timeline based on the effort required for each sprint.

This relationship between time and story points becomes more predictable as our team works together longer and gets into a groove. We also leverage this insight to address issues and mitigate risks early.

For instance, a task with 3 story points usually takes 15 hours for our team. If a developer had a 3-story-point task and spent 25 hours on it, we know that something is up and we need to do something about it.

This estimation method, along with our relentlessness in tracking and analyzing our time, has helped the team cultivate awareness of how we spend our time.

Although we’re creating new software for a new platform, we can leverage what we know about our pace based on what we have done for 7pace Timetracker for Azure DevOps.

We use previous story points, time estimation, and pace to guide our estimates for the new product. Tracking individual tasks granularly has given us a substantial advantage over simply having vague ideas such as “I spent 41.5 hrs this week on dev work” (which is how other time trackers do it.)

The insights, in turn, allows us to create increasingly accurate estimations. (That’s why we are big fans of time tracking.)

Wrangling a Different Beast: Estimating a New Project

Estimating for projects or tasks we have never done before can be tricky.

Although we have historical data to draw from, we didn’t know if it’s accurate. We needed insights fast to help us validate the pace we’re applying to our calculation.

There’s only one way to find out — by doing it.

So we dug in. We started with short sprints until a consistent pace emerged. When this pattern stabilizes, we could see how the number of hours spent correlates with story points.

The ultimate goal for building 7pace for GitHub is to help developers track, own, and manage their time and work data seamlessly — so you don’t have to jump through hoops as we did, whether you’re working on tasks you know like the back of your hand or venturing into new territory.

In fact, we’re using an internal version of this estimation feature to help users estimate timeline based on story points and pace and we’re excited to make this useful function to GitHub users.

Of course, estimation isn’t our only challenge. We also have to tackle resource allocation, plan our go-to-market strategy, and build our beta audience.

Want to find out how it all goes down?

We’ll be sharing new posts and teardowns of our product development process. We’ll share insights and lessons along the way—join us to see what happens.