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 experiences and what we have learned along the way. Here’s how it all started.

We all have some sort of a love-hate relationship with launch dates.

With the limited timeframe, we can’t include all the bells and whistles in one go.

Without the limited time, we’d be tinkering forever, and nothing gets to see the light of the day.

Launch dates give us the reality check to make things happen.

So, how do you determine the release date? Do we throw darts at a calendar, or is there a method to the madness?

Here’s how it typically goes down here at 7pace. It’s no different as we plan to unleash our new product, 7pace For GitHub.

1. Define the Scope

First, we decide what will be included in the release by determining what we want the user to achieve. This step is pretty straightforward for this build: We want users to sign up, onboard, and use the system for time tracking.

2. Break Down the Scope

We then define each component in the scope and map out what’s expected at launch.

To allow users to sign up, we need a signup process. To get them onboarded, we need a walkthrough sequence. For them to use our system, we need to have time tracking capabilities. To encourage adoption, we’re adding a Chrome extension.

3. List Out the Features

We split the components into features and create a scope for each functionality at a granular level, which we log into an Excel spreadsheet.

Next, we break into small groups to create an estimate for each feature using story points. During this step, we won’t see the estimations from other groups.

4. Finalize the Estimations

After each small group has made its estimations, we compare our numbers. Usually, they’re quite similar and it means we’re on the same page. We’d take the highest estimate for each feature and add a 20% (sometimes more) buffer to arrive at the final estimations.

On the other hand, a substantial difference among the estimates often means that what needs to be done isn’t clear. We’d then need to refine the scope, add more details, and go through the same process again.

5. Map the Estimations on Teams

We summarize the story points, apply pace to estimate our timeline (time = pace x story points), and map it onto Teams. We did this exercise in April for our new GitHub application and determined that the product will be ready for beta launch at the end of July or early August.

6. Set Incremental Milestones

How do you eat an elephant? One bite at a time!

We break down main deliverables into smaller milestones so we can measure progress more granularly. This also gives us the opportunity to revisit scope, content, and dates regularly for the more important milestones.

7. Balance Other Considerations

You can’t launch a product in a vacuum. Our next step is to see how the release date works with everything else in the real world.

We realized that August is typically vacation time for many people, so we decided to move the beta launch to the end of July.

8. Make Tweaks To Make It Work

The agile development process allows us to fine-tune the scope and prioritize features as we go. We’ll balance time, resources, and features during the development process so we can hit the July release date.

Watch This Project Unfold

While we wrangled with story points and Excel, we also updated the 7pace application and switched from Azure DevOps to GitHub so we can track, add, and review time in GitHub, just like we do in Azure DevOps.

Our next milestone is the public launch in Q3 2021.

What adjustments will we need to make to hit the launch date? Will any monkey wrench be thrown our way, and how will we deal with that?

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.