Client, executives, and business owners always have one question at the start of a software project:

“When will it be done?”

If you’ve been working in software development for more than a month, you know this question is a trap.

Software development isn’t an assembly line where each task is measured down to the second. You’re creating a product that’s literally never existed before. There will always be uncertainty about the timeline.

Even so, software development is a business, so we have to accommodate the people we build software for.

They need the best estimate we can give them, and we need to avoid promising something we can’t deliver.

Which brings me to the focus of this article:

How can I create an estimated timeline that my stakeholders will accept—but won’t lead to unrealistic deadlines for me and my team?

Ideal Days vs. Story Points: Two Common Methods

In the quest to create better project estimates, developers have come up with all kinds of systems.

Two very common ones are:

1. Ideal days (or similar time-based estimates)
2. Story points

Both can be used to create project timelines, and both have their pros and cons.

One method is reliable, data-driven, and stable.

The other?

You can make it work. But it’s a bit more like crossing your fingers and hoping for the best.

1. Ideal Days: Advantages and Disadvantages

Here’s a simple definition of for the ideal days method of estimating work:
Ideal days is an estimate of the number of days your team would take to complete a project if they worked on nothing else and had no interruptions.
In this context, “interruptions” means anything that causes the team to stop work on the project, including team meetings, training, other projects, illness, etc.

For example, a team of three developers might estimate a total of 45 ideal days to complete a project. If they had no interruptions and worked on nothing else, that would be an estimated timeline of 15 days.

No team exists without at least some interruptions.

For that reason, many teams might estimate somewhere between 20 and 30 days in this situation, depending on how optimistic (or realistic) they are.

Pros of Ideal Days

There are two main pros to the ideal days method:

It’s concrete and intuitive
Clients and outside stakeholders understand it immediately
When you tell a client, “this project should take 20 days,” you don’t have to educate them about the process you’re using or a new idea. They already understand the concept of time estimates expressed in hours, days, or months.

In most cases, clients and outside stakeholders will ask for an estimate given in days, weeks, or months—which is the main reason the ideal days method is so popular.

Cons of Ideal Days

There are three major problems with the ideal days method:

• Human beings are scientifically proven to be outrageously bad at estimating how long things will take;
• Ideal days are often calculated based on the ideal case scenario, not a data-backed review of actual work completed on similar projects;
• In practice, software teams often miss their promise date when using the ideal days method.

This is not news to developers, of course. It’s no secret that we’re all bad at estimating time.

Despite these drawbacks, though, ideal days remain a popular method of estimating time. That brings us to the other most popular method: Story points.

2. Story Points: Advantages and Disadvantages

Here’s a definition of story points:
Story points are an estimate of the effort—not time—required to complete a task within a larger project.
As you probably know if you’re reading this article, the term “story points” comes from the idea of user stories, a key idea within Scrum and Agile project management methodologies.

If you’re creating a new report for small business owners, for example, your user story might say:

As a small business owner, I want a daily report of my revenue for the previous day.

Story points are the estimates of the effort it will take to build all the features needed to create the experience described in the user story.

Story Points Use a Relative Scale

Story points are often assigned using the Fibonacci numbers (1, 2, 3, 5, 8, 13, 21, etc.) or some other relative scale.

We may not know exactly how big a task is, but we know that changing a background from blue to green might be a 1 while building a new drop-down menu might be a 3 by comparison.

Importantly, you should never, ever mix story points with ideal days or any other time-based estimation method. That includes the common practice of pegging story points to a certain number of hours or days (e.g., “One story point = one day”).
Doing so strips your team of the most powerful reason to use story points—increasing your velocity.

Pros of Story Points

High-performance software teams don’t operate at one speed.

Instead, as they work their way through a project, they find ways to do it better, faster, and with less waste.

That means two vitally important things for your team:

After you’ve been through three sprints, you will have a very strong understanding of how fast the team is moving—its velocity;
The velocity will increase over time as the team finds new ways to complete the work faster and with less waste.
For example, it may take your team five days to complete the first 100 points of a project.

If so, your velocity over that first week is 100.

Story Points Example Estimate

Say you’re using one-week sprints for a 1,000 point project.

After three sprints, the team completes 104, 109, and 117 story points, respectively.

That’s an average velocity of 110, which is very strong evidence of the team’s capacity for this particular project even with normal interruptions. This is in stark contrast to the ideal days method, which assumes no interruptions and no other priorities.

You can now go to your stakeholders and confidently report that the 1,000 point project should be complete in a total of nine weeks.

If your team is increasing its velocity as it works (as it should!) there is a very good chance you’ll be able to deliver the project ahead of your promised delivery date.

The Cons of Story Points

While story points have many advantages, there are a few downsides, including:

• Story points are abstract and difficult to understand;
• You might not be able to make a good timeline estimate right at the outset of a new project;
• You’ll have to work hard to educate clients about the method and communicate with them often about the team’s progress.
• The abstract nature of story points means you’ll have to work much harder at communicating with clients, executives, and outside stakeholders.

At the beginning of the project, they’ll want you to tell them exactly how long the project will take—along with how much it will cost.

And in truth, you won’t really have an accurate estimate for them. It will be three sprints before you have an accurate velocity number you can use to make a data-backed projection.

For that reason, your initial estimates will be more uncertain than your estimates once you get the team moving.

That issue will be a point of concern for many clients, salespeople, or executives. They’ll want a firm timeline before they approve the project.

Luckily, there’s a straightforward way to create high-quality initial estimates even before you have a data-backed velocity number.

How to Create an Initial Delivery Estimate Using Story Points

The good news is: initial estimates using the story point method aren’t any less uncertain than the ideal days method.

If your team has completed similar projects to the one being proposed, review the completed sprint boards, then use the velocity the team achieved on those projects as a starting point for your estimate.

This lets you create realistic, data-backed estimates for the timeline of your project, ones that will get more accurate as you begin the project and start completing the work.

As a bonus, if you review the completed sprint boards of similar projects with your client or stakeholders as you give them your initial estimate, it will make you look like you really know what you’re doing.

Data-driven methods have that effect on people. 🙂

Story Points Create Better Outcomes

Despite its downsides, we believe story points create better outcomes for everyone involved in software development, including:

• Fewer last-minute overtime or weekend work;
• More on-time projects;
• Happier clients;
• Happier developers;
• Less overtime and write-offs—which leads to more profitable projects.
• Use Time Tracking with Story Points for Full Visibility Within Your Sprints
• Story points are awesome for scoping and planning work, and velocity (once you have a real number based on at least iterations) is the most accurate way we know to calculate project timelines.

Together, story points and velocity are the antidote to fussy clients who want to know: “How long will this take!?”

Internally, however, once you’re inside a sprint, story points leave a gap in your visibility to the work being completed.

For example, imagine your team sets 20 points of work for a two-week sprint.

In Scrum, you never move a task to “complete” until it’s fully complete—ready for the user to use.

Five days into a ten-day sprint, you might still have 20 points remaining as “unfinished” on the sprint board.

You’re halfway through the sprint, but you have no information about how it’s going. You have 20 points of work remaining, but will it take five days to complete as you planned? Three days? 15 days?

At this point in the sprint, you have no data to make that projection.

It’s a bit like waking up in the morning, looking at your clock, but the only data you see is the year. It’s useful to know what year we’re in, but it doesn’t tell you if you’re running late for work.

Time Tracking Lets You Optimize the Work Within a Sprints
This is where time tracking comes in—not for public reports or timeline estimates to send to clients or outside stakeholders—but for internal tracking—so you know what’s happening during the sprint and can adjust accordingly.

For example, 7pace’s built-in time tracking application will show you exactly how long each team member has spent on each task in the sprint and how much more needs to be done.

This all happens without your team needing to do a lot of work to log every single task—it’s just built into the software.

That time tracking data lets you know if work is being done on the various tasks you’ve planned for the sprint.

If you’re five days into a sprint with 20 story points and work has only been done on four of those story points, you know you have a problem.

Time tracking lets you adjust and optimize work within the sprint—well before the last day or your retrospective.

That way there are no surprises.

How to Use Ideal Days (If You Must!)

Despite our love for data-driven methods, we know that some of you will choose ideal days or another time-based method.

You may be forced to, in fact—by your boss, by a client, or maybe even by your team.

We know one development lead who tried to get his team to move to story points, but they simply wouldn’t break the habit of associating story points to days.

If you must use ideal days, here’s what we recommend:

Calculate your ideal days estimate, then add two or three times as many days to that total.
This will give you a buffer of time to respond to interruptions, illnesses in the team, rework, and shifting priorities.

Then, keep track of how close you were on your estimate.

Say you estimated 100 ideal days for a five person team.

100 ideal days / 5 team members = 20 ideal days to completion
Then you delivered the project in eight weeks.

Actual delivery = 40 days
That’s a 4X factor, which you can use the next time you estimate a project timeline.

Ideal days x 4 = Realistic estimate for project completion
Beware putting too much trust in this method.

As we said earlier, it’s a bit like crossing your fingers and hoping for the best. Even when you use a data-backed estimate in this way, you’ll still have some projects that take far longer than you think.

But at least this gets you working with data—not just crossing your fingers and hoping for the best.

Final Thoughts: Ideal Days vs. Story Points

In the end, the point of estimates is to avoid getting everyone in trouble when you miss your timeline.

Between the two methods, story points is the more accurate way to create timelines and track projects.

But you can make do with ideal days too—if you must.

Whatever you do, use as much data as you can when you make your estimate.

Guessing blind? That’s asking for trouble.

In the end, every software team wants to deliver high-quality products, on time, and on (or under!) budget.

As far as we know, there is no better method for estimating how long a project will take than the story points method.

You will need to be extra diligent about communicating with clients and stakeholders when using the story points method.

But when combined with time tracking for internal project tracking, story points will give you the best chance of getting great results, accurate estimates, happy clients, and a happier, higher-performing development team.

7pace Timetracker is the only integrated, professional time management solution for teams using Azure DevOps and GitHub.