How to Estimate Software Delivery

If you're building software at a startup, there's one truth you can count on:

You can't deliver on time if you don't know what you're building or how long it will take.

That’s where estimation comes in. When done right, you’ll be able to:

• Forecast launches more confidently
• Keep your team aligned and focused
• Avoid over-promising and burning out your developers

And the good news? You only need 3 things:

• A task manager (like Notion, Jira, Trello, etc.)
• 2 short planning meetings
• A spreadsheet (which we’ll give you)

The Estimation Formula

At its core, estimating software delivery comes down to this:

Tasks to complete + Team’s available time = Your estimate

Obvious, I know, but to actually do this, we'll break it into 4 parts:

1. Know what needs to get done (your roadmap)
2. Know what your team can actually do in a sprint (their capacity)
3. Assign work and get estimates (your sprint planning)
4. Estimate for the future (their velocity)

Step 1: Clarify What You’re Building

Before you can plan sprints or write estimates, your team needs to know what they’re building and why.

✍️ Set up your roadmap

Use a tool your team already knows: Notion, Trello, Jira, ClickUp—whatever. What matters is that everyone has access and can see what’s coming.

To save you time, here’s a free Notion template that includes:

• GANTT-style roadmap
• Task table with embedded fields
• Priority tagging and owner fields

📅 Schedule and Facilitate a Product Increment (PI) Planning Meeting (meeting 1/2)

Invite your:

• Tech lead
• Product Owner / Head of Product / UX designer
• Stakeholders

The goal: Agree on what needs to be built for the next milestone (aka "version").

Duration: 2 hours. When you start, it'll take the full 2 but once you get used to it, it'll only take 1 to 1.5 hours

Use this agenda

                Product Implement Planning
                Duration: 2 hours
                Attendees: Product Owner, Tech Lead, Stakeholders
                Agenda:
                - What’s the core version of our product we want to ship?
                - What tasks or features must be included?
                - Are there any dependencies or blockers?
                - What’s the rough target date for launch?
                - Any risks to delivery? (such as tech debt, large holiday coming up, lots of team members out on PTO, etc.)
              

Assign someone to take notes and write the agreed-upon features as tasks into your task manager. If you know your task manager well, then you can take notes, update the task manager, and run the meeting.

✨ Tip: Keep it lean. Don’t add everything you want; just what you need to ship for this particular feature release.

Step 2: Estimate Your Team’s Capacity

Now that you know the work, you need to know how much your team can realistically get done. Let's measure your team's capacity!

📈 How to Use the Capacity Planning Sheet

1. 🏋️️ Sprint Configuration

This section defines the overall sprint parameters and working context. Fill this out first:

• Number of Days in Sprint: Usually 10 (for two-week sprints).
• Working Day (in hours): Typically 8 hours.
• Company Holidays: Days off due to holidays.
• Lost Work Days: Sprint delays or early closures.
• Time for Sprint Ceremonies: Est. hours per person (e.g., 2-3 hrs).
• Time for Daily Standups: Usually 0.25 hrs x number of days.
• Non-Admin %: Time available for actual development (default 80%).

2. 🌴 Team PTO

List each team member and how many full days they are taking off during the sprint. This directly impacts their availability and is factored into the next section. For example, Team Member 1 is Tony and he has 1/15/25, 1/17/25, and 1/21/25 off.

3. 📝 Team Capacity Configuration

First: Change all the place holder team members with your own team and group them by department (if you so choose - e.g. frontend, backend, QA, etc.)

Second: Input the "Number of PTO days in Sprint" row for each team member. To collect the info, either message the team before you hold the sprint planning meeting or collect it during the meeting. I would recommend doing it before so you do not waste time during planning.

Next: Let the sheet do the rest!

This calculates each team member’s total available hours using what you input and the following:

• PTO Hours: Days off multiplied by daily working hours
• Ceremony/Standup Time: From the configuration above
• Non-Admin Time: 80% of working hours minus ceremonies and PTO
• Availability: Final number of hours available to write code or design features

The sheet is color-coded by department (e.g., design, engineering, QA) and each member has a column. This gives you a full snapshot of team-wide capacity.

4. 📥 Add Tasks to the Sprint

From your task manager, copy/paste only the titles of high-priority tasks into the ticket section of the spreadsheet. You don’t need descriptions—just enough to identify them.

You do not need to fill in the other cells next to the task titles yet.

These are the tasks your team will estimate in the next planning meeting (this one). The cells next to the tickets are the estimates you will discuss with your team.

5. 🔄 Team Sprint Allocation / Utilization

This last section summarizes how well you’ve allocated your team's time. It helps you make sure your team isn’t overbooked or underused.

It updates automatically as you assign estimates. You do not need to fill out anything here.

• Total Hours Allocated: Sum of assigned estimates per person.
• Total Hours Remaining: Difference between capacity and allocation.
• Sprint Utilization: Percentage of team capacity filled.

If a developer is at 100%, they’re fully booked. If someone is below 80%, consider redistributing work. If over 100%, they’re likely to burn out or miss deadlines.

Step 3: Run a Sprint Planning Meeting (meeting 2/2)

Now bring your team together for your second meeting.

Invite Your:

• Your entire tech team
• Tech Lead
• Product Owner / Head of Product / UX designer

No stakeholders needed.

The goal: Assign tasks to team members and estimate how long each one will take.

Use this agenda:

            Sprint Planning
            Duration: 1–2 hours
            Attendees: Tech Team, Tech Lead, Product Owner
            Agenda:
            1. Review the sprint goal
            2. Go over high-priority tasks from the roadmap
            3. For each task:
              - Assign it to a team member
              - Estimate the effort (hours or story points)
            4. Check capacity and utilization for each person
            5. Adjust if anyone is overbooked or underbooked
            6. Confirm everyone understands what they’re committing to
            7. End with Q&A or clarification
            

Note: Story points are explained in step 4 in this sectionhere

Learn the steps from the image (below) beforehand. During the meeting, guide your team through these steps.

Step 1: Double check the sprint configuration section fields with the team. Often times people forget there is a company holiday so the third field is wrong.

Step 2: Double check with the team for any PTO days. Sometimes even if you message the team beforehand, a new PTO day comes up that has to be updated so check this with the team as well.

Step 3: Enter the number of PTO days each team member has. For instance, from our previous example if Tony has 1/15/25, 1/17/25, and 1/21/25 off, I would write down "3" in cell B14.

Step 4: Now we estimate! Go through each ticket and assign it to a team member, then ask how long it'll take. "Length" is determined by one of two ways.

1. Story points (recommended for advanced teams): Choose 1, 2, 3, 5, or 8 with 1 being the least effort and 8 being the most effort. This is used to measure effort and not time. You choose a number that shows how complex, risky, or big the task feels compared to others.
   • The numbers usually come from the Fibonacci sequence — 1, 2, 3, 5, 8 — because they don’t go up evenly. This helps teams focus on relative size. For example:
   • A 1-point task is super small and straightforward.
   • A 3-point task takes more effort — maybe it’s a bit complex or has some unknowns.
   • An 8-point task is large and will take significant effort — it might have technical risks or require more coordination.
   • Why not just use 4, 6, or 7? Because choosing between closely ranked numbers like 5 and 6 isn't helpful. Using a spaced-out scale forces you to make clearer decisions.
   • Story points help your team compare tasks to each other instead of guessing hours. Over time, you'll get better at knowing how many points your team can finish in a sprint — which makes planning much easier.
2. Hours (recommended for junior teams - training wheels): Hours are straightforward. If you choose this, you just ask how long they think the task will take.
   • We use hours for junior teams because they most likely do not know exactly how long a task will take.
   • It is MUCH easier for them to get a sense of clarity during a team reflection, like sprint retrospective, on how accurate their estimate was.
   • Once they’re consistent, you can introduce story points.

Whichever estimation unit you decide to use,

1. go through each task already loaded onto the sheet
2. ask the team who is most likely the best person to handle the task
3. then ask the chosen team member how many hours or story points the task should be

Step 5: Once all the tasks are listed, assigned, and estimated, go through the sprint allocation section and check the row "Sprint Utilization". Make sure your team is at least at 90% or above. Talk with your team and see if everyone agrees with the plan.

✨ Tip: Try not to overfill a sprint. Leave a little wiggle room for unexpected tasks.

Sprint Planning is now done!

Step 4 (Final Step!): Estimate Your Team's Velocity

Once you've completed at least 2 sprints, you can calculate each team member's velocity:

Velocity = average hours (or points) completed per sprint Example:

Dev Tony: Sprint 1 he completed 30 hours and in Sprint 2, he completed 34 hours. His Velocity = (30+34)/2 = 32

You can use this number to forecast how long bigger features or milestones will take. In your product planning meeting, if a task is determined to be 64 hours and you know Tony works on tasks like this, he is most likely to take it. You can estimate about how long the new feature will take by using Tony's velocity. Let's just say it is 32, that’s 2 sprints (32 + 32 = 64).

In a seperate sheet, write down every team member's velocity. You can use the Velocity Tracker to do this. Keep a running log of how much work each team member finishes every sprint. Start filling it out after Sprint 1 is done — just ask your team how many hours or story points they actually completed, and write that number under their name. Do the same thing after Sprint 2. You won’t get a velocity estimate until both Sprint 1 and 2 are complete, since the tracker needs at least two sprints to calculate an average. Once that happens, the sheet will start showing each person’s average velocity — and it’ll use that number to estimate how much work they can handle in future sprints. As you keep filling it in, earlier rows stay as real data and future rows show projections to help with planning.

This formula and sheet also works for story points!

Note: This has mock data so the rest of the rows after Sprint 7 are more or less the same.

Here is the velocity tracking document. Just like everything here, it is yours to keep for free. Use it religiously and I promise you will have a more accurate tool for estimating and planning.

🔁 Recap: How to Estimate Software Delivery at a Startup

Estimation doesn’t have to be complicated. Here’s the high-level playbook:

1. 📌 Know what you’re building
   Use a roadmap everyone can see (on Notion, Trello, ClickUp, or etc.). Run a product planning meeting with your tech lead, product owner, and stakeholders to figure out what should be in the next version.
   → Add those tasks to your task manager.


2. 🧮 Calculate your team’s capacity
   Use the Capacity Planning Sheet to figure out how many hours (or story points) your team can realistically work in the upcoming sprint.
   → Make sure holidays, PTO, and meeting times are factored in.


3. 📅 Run a Sprint Planning Meeting
   In this meeting, assign each task to someone and ask how long it’ll take. You can use:
   • Story points if your team is experienced
   • Hours if your team is still new
   → Check the utilization section and make sure no one is overloaded or sitting idle.


4. 🚀 Track your team’s velocity
   After 2+ sprints, calculate each person’s average output.
   → This helps you forecast how long big features will take in the future.

📂 Resources to make this easier:

• ✅ Task Manager of your choice (Notion, Jira, Trello...)
• ✅ Capacity Planning Sheet
• ✅ Velocity Tracker

✨ And we're done! You’ve now got the full toolkit to plan like a pro. Now it’s just about using it every sprint and adjusting along the way. It will get easier the more times you do it. The key is being prepared (that is why we provided all these tools).