We’re all used to estimates for general contract work where, in almost all cases, the estimate received is based on work hours.
When working with software development companies that use Agile, you’re likely to be introduced to “story points,” sometimes simply referred to as “points.”
Agile represents an entire way of approaching the design, building, and release of software. It’s primary focus is to drive the delivery of a highly usable solution through an iterative process.
Software development companies that use Agile measure the effort of their work in points.
(If you’re interested in learning more, read the Agile Manifesto and the 12 Principles Behind the Agile Manifesto!)
So, what IS a point?
Why do software companies use points?
And, why should you even care?
Story points are a huge benefit to both the software developer and stakeholders when implemented properly.
What are story points?
Story points are a comparative measurement of effort required for performing a task.
Story points, unlike hours, do not take into account the skills, experience, and mood of the person doing the work. Rather, story points are based solely on the comparative complexity of the task at hand.
When software teams use points, they’re typically looking at how much work goes into completing the task at hand, its complexity, and any uncertainty that may require additional research.
The higher the value, the more effort the task requires—and everything is relative.
A two-point task takes twice as much effort as a one-point and two-thirds as much effort as three points.
Typically, point values are used based on the Fibonacci Sequence (0, 1, 2, 3, 5, 8, 13, 21, …).
This is because as the amount of work increases with a task, it becomes both impractical and inaccurate to distinguish estimates at a finer level.
One story point is equal to how many hours?
There is no consistent ratio of points to hours and that’s because…
…Points are not relative to hours or time!
The same task can take different amounts of time when performed by different people, or even the same person at a different time.
Instead of looking at hours as a means of measuring work, points provide a way to compare tasks to similar work based on the complexity and effort required.
Points also give the stakeholder an opportunity to focus on what they need out of the end product and the relative value it will provide rather than thinking about how many work hours it should take for someone to complete the work.
How long does it take to get work done with points?
The time it takes to get work done is based on a team’s capacity and velocity.
Velocity is the amount of work a team or individual is able to accomplish in a given timeframe.
So if your project takes 100 points of effort and the software development team is able to handle 25 points a week with their current capacity, you can expect a timeline of four weeks.
A development team that understands their capacity and velocity well will easily be able to give you dates for checkpoints and deadlines for a given scope of work.
Some developers convert between points and hours. That’s a mistake!
There are two common scenarios where vendors relate points to hours.
- As a way to “help” the customer understand points
- To disguise the amount of work being done
Vendors that use story points but talk in hours may purely do this for your convenience. However, points are not relative to hours so there is no value to converting them, which is doing a disservice to you.
Again, it’s about the effort it will take to get the project done, not the hours.
Additionally, just because a software vendor uses points, it doesn’t mean they are good at it!
Using story points and implementing the process to create consistency and reliability is not easy. It requires development companies to complete many projects before mastering.
It’s not uncommon for vendors to have an illegitimate point planning process, which may lead to inaccurate estimates and obscurity over the amount of work being done or what you will be charged for the work.
In all cases, it’s good to review the previous projects of vendors you plan on doing work with and inquire about the method they use for determining points and pricing.
What’s the issue with hours?
One of the biggest drawbacks of using hours is that tasks are now time-dependent and this can cause many inaccuracies, especially with software development where a lot of variables come into play.
For example:
Let’s say a task estimate is for 5 hours.
A senior developer can complete it in 3, whereas a junior level developer takes 8 hours.
The senior developer has extra time to fill the “budget” set. Or, they track their time accurately, and the company loses out because they charge for fewer “hours” of work.
The junior developer needs more time to get the job done or may have to cut corners to meet time expectations. Now the company charges you more just because it took longer because of who it was assigned to.
Using hours in this situation causes estimation issues for both the developer and stakeholders because the same task has a huge variance in hours required to complete it.
Had points been used in this scenario, developers would come to an agreement on the complexity and effort that goes into the task to assign an appropriate point value.
Regardless of whether the senior or junior developer is on the job, the point value doesn’t change.
Why use story points instead of hours?
Story points allow the stakeholder to focus on what they want from the end product and the software team to focus on how the project gets done.
Say you’re getting an estimate for a web portal.
Rather than looking at how to budget for hours, points allow you to focus on deciding the value that technology will provide your business, how much you are willing to spend, and if the product accomplishes your needs.
The software company can then focus on how to get the work done, making sure they understand and document your requirements clearly, assigning story points to the scope of work, providing you with a specific cost based on those points, and determining their team’s velocity and a timeline for getting the project done.
Time doesn’t matter, but deadlines do!
Even though points are not attached to hours or time, deadlines are still just as important.
Vendors that use story points well understand the velocity of their teams and overall capacity and will provide a solid deadline and checkpoints throughout a project.
Myths about story points
Without knowing much about them, story points can be intimidating.
Don’t let these myths deter you from your next project!
Story points are just a different measurement for time.
Time ≠ Points.
While both hours and points can be used to produce an estimate and timeline, points are purely a measurement of effort.
The speed at which points are completed is dependent on a development team’s velocity.
Points inflate numbers.
The actual numbers used don’t matter. What matters is what that task is being compared to.
A task worth 100 points should be twice as much effort as a 50 point task.
Points are all about ratios and comparisons to similar work that has been completed in the past.
Only developers understand story points.
For now!
Soon many more people will understand points as more developers continue to adopt the process and projects continue to be completed.
Once people understand the ratio of task values to each other and the velocity at which a team can work, using points for planning becomes a lot easier.
So… What IS the point of points and why should you care?
OK, let’s get to the point.
Many software development companies now use story points because of the value it brings to estimating and task management.
What matters most, however, are the benefits it provides to you, the stakeholder.
Benefits of story points for project stakeholders:
- Estimates are more accurate
- Tasks won’t be stretched out to fill over estimated hours
- Point values don’t change based on individual skill level
- You won’t get overcharged for the inefficiency of developers
- Gives the vendor incentive to complete work as efficiently as possible
- Makes the vendor accountable for how the work gets done
- Allows stakeholder to focus on the value and outcome of the project
As more people continue to adopt story points, the developers who put the time in to mastering the Agile process will reap great benefits for their team and clients.
And for the businesses that partner with these experienced developers, they will find the most success implementing new software projects.
I hope this has helped you gain an understanding of story points and that they are no longer intimidating.
And, maybe you’ll even find yourself interested in measuring your own work using points.
If you are currently comparing estimates for your next software project…
