In traditional software development, teams would describe the amount of work they had in hours. But Agile software development teams have a better way. Agile teams use Story Points to estimate the work they have ahead of them. Let’s take a closer look at Story Points and hours, and examine the benefits of Story Points.
Hours
Teams using hourly estimation try to give an educated guess about how long a feature or bug fix will take to complete. Often they might do this without a full understanding of the complexity of the Sprint ahead. Agile teams may find that hourly estimation causes trouble for them. If they estimate too many hours and finish early, they look like poor estimators. If they take more hours than the estimate, they look like they lack the skills or speed to work as required. The team may also face scope creep and unforeseen obstacles. All these factors make hourly estimation less than ideal.
Story Points
Agile teams use Story Points as a metric to measure the difficulty of a particular User Story. (We remember that Agile Sprints use User Stories as their base. The Agile Team describes a feature or bug in plain language from the perspective of the end-user. That description is our User Story). Story Points seek to measure at least three categories:
The total extent of work
The complexity of work
Risks and uncertainty
Related post: Use Cases vs. User Stories: relationships and differences
How do you convert story points to hours?
Some more traditionally-minded organizations might allow teams to estimate in Story Points and then ask them to convert this into hours. Doing this is worse than comparing apples to oranges. It’s more like comparing a smartphone to a car. Agile Teams create Story Points to give measure to work needed. By meeting with the whole team, including junior and senior developers, they estimate their Story Points.
The same story point might take one developer eight hours and another developer four hours. Agile teams set Story Points based on relative difficulty. Story Points are by their nature abstract measures. Teams use Story Points because they allow team members who work at different speeds to estimate and collaborate. The team members can agree that a User Story might take twice as long as a previous and similar Story. They then assign a value double the first one Story. So it’s not a discrepancy of several hours depending on who works on the task, but a Story Point that measures comparative difficulty.
When the organization asks the team to convert Story Points to hours, they lose the benefits of using a conceptual calculation. While abstract, Story Points carry meaning and weight that we cannot force into an hourly estimation
However, if the team works for an external client a hybrid method functions, albeit not ideally. Clients may find it difficult to understand why Agile teams prefer Story Points over hours. The team could use a hybrid approach, where Story Points correspond to a rough number of hours. This approach proves less than ideal, though clients may find it easier to understand.
When developers estimate in hours they might fall short or overshoot their target. Neither way works well for clients or for the team.
Why are Story Points better than hours?
Savvy Agile teams use Story Points to compare features in the current project with similar features from previous projects. Then the team gains a better understanding of exactly how much work they need to accomplish. The team members then give a value to the Story Point based on the complexity of the task. If the team does not have previous projects, they create a Base Story and Estimation Matrix.
Let’s examine the main benefits of using Story points over hours:
Story Points are flexible
Teams track Velocity
Story Points work better at high-level estimation
Teams do not have to re-calibrate their estimation if Velocity changes
Agile teams like to use Story Points estimation because Story Points use Velocity. Velocity helps them plan for capacity. Velocity allows them to work faster when possible. Team members spend time discussing how to improve their Velocity and work more efficiently in the Sprint Retrospective. Velocity is changeable during projects and Sprints. By using Story Points, the team doesn’t have to change their estimate if Velocity changes. If they were to estimate with hours the story would be very different.
Story Point Pros and Cons
Pro | Con |
The entire team helps with the estimation | Clients can have difficulty understanding Story Points |
More collaborative, less finger-pointing at slower-working developers | Sharp learning curve, teams may need several Sprints to estimate Story Points with some precision |
Less worry about the clock and the calendar | |
Tasks examined closely, the difficulty of work easy to see | |
Teams estimate based on abstract measure, not specific developer’s speed or skill |
Hourly Estimation Pros and Cons
Pro | Con |
Good for smaller projects where the team understands the task completely | Highlights the weakest or slowest developer |
Velocity is not important to estimate | Hourly estimates link directly with a specific developer |
Clock and calendar watching create tension and stress for the team | |
Hourly estimates prove unreliable | |
Here at Blocshop, we take full advantage of Story Points to prioritize our work. We believe the power of Agile gives us an advantage when it comes to software development. We work fast and under budget because we plan and estimate fluently. If you’d like to learn more about how Blocshop can help you with your software development project, please do get in touch!
