No spam, no B.S.
Unsubscribe if you’re not happy.
Client, executives, and business owners always have one question at the start of a software project:
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:
GRAPHIC
In the quest to create better project estimates, developers have come up with all kinds of systems.
Two very common ones are:
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.
Here’s a simple definition of for the ideal days method of estimating work:
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.
There are two main pros to the ideal days method:
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.
There are three major problems with 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.
Here’s a definition of story points:
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 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.
Doing so strips your team of the most powerful reason to use story points—increasing your velocity.
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:
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.
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.
While story points have many advantages, there are a few downsides, including:
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.
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. 🙂
Despite its downsides, we believe story points create better outcomes for everyone involved in software development, including:
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.
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.
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:
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.
Then you delivered the project in eight weeks.
That’s a 4X factor, which you can use the next time you estimate a project timeline.
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.
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.
No spam, no B.S.
Unsubscribe if you’re not happy.
