Wrapping your mind around software development processes can be hard. When you come up with an idea and approach developers with it, the first two things you ask are how much it will cost to implement and how long it will take to build. Estimation is one of the first steps in app development.
In this article, we compare the two most popular estimation models in modern software development: Agile story points vs hours.
Read on to learn how to estimate time in Agile, get the gist of both estimation models, understand their differences, and see why developers might choose one over the other.
- What exactly are story points?
- Here’s how story points are calculated in Agile
- Advantages of estimating in story points
- Disadvantages of estimating in story points
- Advantages of estimating in hours
- Disadvantages of estimating in hours
- Can you convert story points into hours?
- What to choose for software development?
Hours are pretty easy to understand, and they’ve been the primary estimation model in software development for a long time. Hours, also known as man-hours or worker-hours, are the number of hours a developer spends on the project.
So what are story points and why did they emerge if we’ve already got a simple and straightforward estimation model?
What exactly are story points?
Story points are a relative estimation model native to Agile and Scrum. They estimate the effort to build a product by addressing three aspects of development:
the amount of work the product requires
the complexity of the product’s features
risks and uncertainties that might affect development
At the very beginning of project evaluation, developers choose the smallest and simplest user story a product has — for example, a sign-up user story — and set it as a 1-point user story. That’s the base story: a user story that will be used for complexity comparisons. All other user stories will be assigned a number of story points based on how complex they are to develop compared to the base story.
Looks simple enough on the surface, but who decides on the number of story points in each story?
Here’s how story points are calculated in Agile
As with hours, the people who will work on the product usually estimate story points for development. However, the estimation process is slightly different with story points.
To assign story points to a user story, several developers are involved. There should be at least two, but the company can ask all their developers to contribute by playing what the industry calls Planning Poker. Here are the rules of the game:
Each developer gets a set of Planning Poker cards.
Developers choose a user story and discuss its complexity and the development effort needed.
Each developer puts forward a card corresponding to the number of points they’d assign to the story.
If the story point estimates are the same, the estimated number of points is assigned to the story.
If the suggested story points differ, the developers discuss the user story until they come up with a number of points approved by the majority.
Developers choose the next user story.
Repeat steps 3 through 5.
When our activities all went remote, this process has been modified. Instead of cards and meetings, the story points are decided in online discussions, during Zoom meetings, or in messengers.
It looks kind of like this:
This doesn’t mean all the developers involved in estimating story points will work on the project, of course. But a key advantage of the story points system is that it creates a more or less universal framework that can be used not just on the project in question but also on future projects with similar features.
There are two frequently used options for estimating story points. You can assign points:
using any whole numbers (1, 2, 3… 13,14,15, etc.)
using numbers in the Fibonacci sequence (1, 2, 3, 5, 8, 13… 55, 89, 144, etc.)
The Fibonacci sequence is a more convenient option for estimating development as it leaves some margin for approximation. The numerical order model is a little too precise for convenient comparisons.
During development and between projects, if the user story ends up being either more or less complex than originally estimated, assigned story points might be changed.
Advantages of estimating in story points
If the process of assigning story points looks a bit complex, don’t let it throw you off. There are advantages to capacity planning with story points.
1. Story points are developer-independent
Story points for each story are assigned by several developers in negotiation, and the reason for that is that the number is assigned not just for one particular product and one particular developer but “on average.” Why is this a good thing?
Things happen. Sometimes, your project’s developer might leave your project and be replaced. Maybe they’ll fall ill, decide to take parental leave or a sabbatical, or simply leave the company. Maybe they’ll turn out to be underqualified or overqualified for the project.
When they’re replaced, a new developer might have a different work speed, which will lead to re-estimating the worker-hours necessary to create the product.
Story points minimize this issue. Assigned by several different developers, they provide a general look at how complex a particular user story is. Story points work for any and all developers in a particular company. (Though please keep in mind that story point estimates will not be correct for different companies.)
2. Story points make it easier to recalculate development time
In Agile time estimation with story points, teams use the term velocity to refer to the number of story points released in a single sprint.
Teams constantly monitor their velocity, and it’s quite variable at the outset. A team can release features worth five story points one week and twenty story points the next. But that’s only at the beginning. As the project progresses, the velocity graph will even out.
With hours, if a team member changes, each task they are involved in will need to be re-estimated to adjust the deadlines. With story points, this is unnecessary — the team can adjust the project deadline after the next sprint by knowing the change in overall velocity.
Story points evaluate team performance as a whole, eliminating the need for re-estimation by task.
3. Story points are good for monitoring team performance
When you have teams working on similar projects and/or tasks at different times, velocity can easily show you the progress each team has made. Have they improved and by how much? Which team or developer struggles and might need extra training? What’s the learning curve? Maybe a different team performs better?
Velocity is a great tool to evaluate your teams’ performance not just on the spot but continuously.
4. Launch time estimation with story points is more precise
By tracking velocity, the team knows with high precision how many story points they can release in one sprint. While it takes some time for the app development team to calculate its velocity, once it’s been calculated, the estimated launch date is easy to predict.
Moreover, changes in team members, requirements, or the number/complexity of features don’t cause many struggles with re-estimation.
5. You can re-use story points for future projects to speed up estimation
It’s not uncommon for a company to be well-versed in a specific niche (or several) and build more than one product with a similar set of features. After completing even one project estimated in story points, developers can refer to this estimate for new projects. This will shorten the time for estimation.
However, it’s important to keep tracking the velocity for each project since circumstances can change.
6. Story points enhance teamwork
Traditionally, development companies have several teams of developers, each working on separate projects. When estimating in hours, it’s the developer working on the project who makes an estimate. This is a good thing, in general, as who knows better how long something will take than the person doing it?
However, estimating complexity in story points offers an opportunity for developers in the same field to cooperate — something that happens rarely otherwise. This kind of teamwork makes for a great chance to share experiences and motivate each other.
Disadvantages of estimating in story points
There’s always the other side to the argument, which is how great systems are born. Complexity-based estimation has its drawbacks as well, and each team has to decide for themselves whether they overweigh the advantages.
1. Story points should be assigned by more than one developer
The selling point of the story points model is its objectiveness and value for future estimates. But for that to be true, the estimation must be done by more than one developer. For small companies with a single team or companies where there’s only one specialist in a field (i.e. only one designer or iOS developer), story points don’t bring as many advantages. Such small companies traditionally choose worker-hours as an estimation model.
2. Estimation in story points requires a considerable backlog
To realize the full potential of story points, your team will need to spend a considerable amount of time. If you’re working on a project with features the team has never worked on previously (or hasn’t worked on full-time), the first two to three sprints will be hard to predict performance-wise. Granted, the more backlog items your teams have, the more precise their estimates can be due to the abundance of statistical data. But story points is not a system that’s ready to go right away.
3. Story points are more complex for budgeting
Story points are great for setting precise deadlines and launch dates, which can be important for developers and for the client’s marketing. However, when it comes to estimating app development costs, they’re less convenient.
The thing is, developers spend time on a project not only on writing code (or making designs, or testing). Some time is spent on research, discussion — inside the team and with the client — making changes, etc. Time spent estimating story points is also time spent on the project, but it’s not included in the points per story.
Budgeting when estimating in story points is possible, but it’s usually faster and easier to equate money to the time spent on the project.
4. Velocity is calculated per team
What this means is that if teams mix between projects, you’ll need to calculate the velocity for each combination of developers separately. Hence, the estimate for one team won’t necessarily be true for a different team, and even changing a single team member can potentially invalidate prior estimates.
On the other hand, you can use complexity estimation to find the best-performing combinations. It’ll take time, though.
Advantages of estimating in hours
While some Agile teams use story points, many have yet to switch from worker-hours. There are important reasons for that. Let’s cover them as well.
1. Hours is a familiar model
Innovation is great, but it takes time. Developers and their clients alike are well-versed in worker-hours estimation. For many, the idea is “if it ain’t broke, don’t fix it.” As long as the system offers workable estimates, why switch to something else?
The difference in the precision of estimates might not be large enough for some developers to change how they do things.
2. Clients usually pay for hours
This needs little elaboration. For clients, complexity-based estimation might be confusing. Moreover, if for the client the budget is more important than the launch date (which it often is), story points won’t be relevant for them.
3. Hours-based estimation can be done by one developer
For small teams or freelancers, story points are largely useless, as they require multiple points of view. Without any reference, estimating in story points is an unnecessary hassle.
Hours, on the other hand, offer the developer working on the project a way to make fairly precise estimates themselves.
The same goes for team velocity. When teams change every time, as happens with freelancers or partial outsourcing, monitoring velocity makes very little sense. Hours-based estimation is the better choice here.
Disadvantages of estimating in hours
Here are the reasons why teams might decide to stop using hours as an estimation model.
1. Being solely responsible for estimation is a lot of pressure
On the one hand, estimating your own time requirements can be easier, as you only rely on yourself.
On the other hand, if you fail to deliver on your estimates, it’s a huge blow. More so if the team waiting to start their tasks is reliant on you completing yours.
Moreover, the stress caused by pressure to deliver what you yourself promised can disrupt an otherwise well-proceeding task.
2. One developer’s estimate is always less precise than a team’s
Individual estimates are subjective and tied to the estimator’s emotional and psychological circumstances.
Some developers tend to overestimate themselves and set time frames they later struggle to uphold. This not only disrupts the development (and lays extra costs on the team if there are fines) but also causes stress and burnout in developers.
Others underestimate their own skills, prolonging development more than objectively needed. Insecurity and a habit to overthink, check, and re-check work often leads to development deadlines being set to later dates — and tasks are rarely completed before deadlines. Team input allows for estimation that’s more objective.
3. The bigger the task, the harder it is to estimate in hours
This correlates with non-development situations as well. It’s easy to say how much time it will take to read a three-page university booklet but harder to estimate how long it will take to finish War and Peace.
The same goes for development. Small tasks are easy to estimate for developers with some experience. The bigger the task, though, the more things — happening both inside the project and outside it — can affect the development. Hours-based estimates do not offer the margins story points have, making estimations rougher.
4. Little flexibility
Hours-based estimation is developer-based. If one team member working on the product changes mid-project, the team will need to recalculate every affected user story still in development or scheduled for future sprints. That can be a lot of work, depending on the stage the project is at and the difference in skills between the original and new developer. Hours-based time estimation is quite rigid.
Can you convert story points into hours?
Clients can ask a team making estimates in story points to convert Agile story points mapping to hours. Most people not familiar with the latest software development trends won’t know what to make of story points.
However, when a client asks how many hours a story point equals, it’s impossible to answer definitively. One of the key components of complexity-based estimation is the effort spent to complete the story. But effort doesn’t directly translate to time spent. Hours address uncertainty in a more vague way than story points.
The more complex the task, the more uncertainty and risks exist. Converting story points to hours in a straightforward way and only relying on velocity doesn’t account for many such risks, since hours-based estimation is more approximate than story points when it comes to risks and uncertainties.
To some degree, using the Fibonacci sequence in assigning story points will account for uncertainty in development times, but it doesn’t exactly allow for a direct conversion.
Here’s an example.
A 1-story point story (base story) takes, let’s say, two hours to complete.
A 13-story point story might take 26 hours in the best-case scenario — if nothing goes awry or gets in the way. For instance, if the API used fits seamlessly, endpoint to endpoint. But if it doesn’t, the story might require anywhere between, say, 30 and 50 hours — depending on how many mismatches there are. No one can say beforehand how it will go if the developer hasn’t yet worked with the API in question.
So in translating story points to hours, there needs to be a multiplier for exponential growth to address the uncertainty. And that multiplier will differ from one team to another.
Story points vs hours: What to choose for software development?
As you can see, both story points and hours are valid choices for a developer to estimate projects.
All in all, we’d say more product companies choose story points while outsourcers tend to lean towards hours.
Companies working with a fixed price model usually go for hours-based estimation. Teams that prefer Scrum often choose story points, as they literally were born from Scrum and are native to this methodology.
In our years of experience, we’ve come to see it this way:
If accurately estimating the launch date is more important than fitting the budget, go for story points.
If the budget is more important than an accurate launch date, consider hours.
Or, best of all, combine the two.
Story points are highly convenient for development teams working on long projects where monitoring velocity will make a difference.
Hours are important for clients who worry about squeezing into their budget. Also, hours make more sense for short-term projects.
The complexity-based system is still fairly young, as is Scrum itself, and it’s still developing. Combining both estimation models and working out a system to quickly change each story point to hours provides benefits of both models while minimizing the drawbacks.