Article Series: Better Estimations in Scrum — Part 1: Story Points vs. Time.
One of the main causes of failure in projects are missed deadlines and/or costs. Having accurate estimates is crucial to avoid these problems.
Sometimes teams commit to more work than they are able to anticipate in a sprint and that can cause carry-over work and a subsequent change in the project roadmap and milestones.
Having precise estimates on the other hand allows for the team to grow, while feeling confident and steadfast in their capabilities. This results in team members who work synchronously with each other while maintaining self-organization.
Also, organizations love predictability! This, in turn, allows for profitability.
At White Prompt, we consider Project Management like taking a look under the hood. From ideation to production, our experienced project managers deliver peace of mind to our clients as the owners of the product roadmap. This process involves communicating clearly and transparently, delegating, and managing the step-by-steps throughout the product’s lifecycle. This allows for more accurate estimates of timelines and maintaining profitability.
Is your team ready to build an exciting project? Contact us today to schedule a free consultation and we will develop an out-of-the-box solution together.
Join us in this 3-part article series where we will discuss 3 of the key aspects that we should consider at the moment of estimating workloads in a team environment.
Story Points vs. Time.
The building blocks of a Scrum project are the User Stories. At the beginning of each sprint the team has to estimate and decide which ones they will commit to for the sprint.
The most common metrics used for estimating are Hours and Story Points. Both have their pros and cons, as the deciding factors depend on the context of the project as well as the team’s composition.
Let’s analyze the two different metrics and summarize their positive and negative attributes accordingly.
Time (“How Long Will It Take?”).
A well-established approach for estimations is to measure the amount of time that a given task is expected to take from start to finish. Then, after summing up and parallelizing the estimates, the team can provide dates for future milestones and identify the amount of work that can be completed during a given sprint. Time is simpler to understand than Story Points since it’s a metric that organizations have been using for decades.
There are several variables to consider for time estimates, such as the expertise of the involved developer and his capacity throughout the sprint. For example, is he fully assigned to the project? How many meetings and scrum ceremonies will he attend during the sprint? Does he have days off or holidays to observe?
As we can see, time estimations are very dependent on the person assigned to the project and very sensitive to fluctuations in the team member’s availability.
Additionally, the more complex the User Stories are, the more difficult it becomes to provide an accurate time estimation since there are too many variables involved in the User Story’s execution.
Pros of using Hours
- It makes the time estimation of small and simple tasks easier.
- It allows for a team to estimate a sprint by the hours capacity, removing the need to consider the team’s velocity.
- Hours are understandable for managers and stakeholders.
Cons of using Hours
- Complex or large User Stories may be underestimated or overestimated.
- Estimations based on time only reflect the capability of the developer who established them.
- If the task is not completed within the given estimated time, there will be stress that may affect performance. As they say, time is ticking which creates unnecessary pressure.
- Very sensitive to context changes such as non-predicted meetings, sick leaves or power outages.
- Tracking progress and deviations is more challenging and time consuming for Project Managers. Any change may imply a recalculation of the plan and making adjustments to the deadlines instituted at the start.
Story Points (“How Big Is It?”).
A Story Point is a metric used in Agile to establish the level of difficulty to implement a specific User Story. This is an abstract measure of effort that a team requires to implement the User Story.
It is important to understand that Story Points don’t have any meaning outside of the team and the context of the project. They are important only when being compared to other stories or tasks that have also been evaluated with Story Points. For instance, one Story may pull an effort of 5 which is valuable to the assessment only if being compared to another Story with an effort of 8. When comparing the two, 5 Story Points is relatively easy while 8 Story Points proves to be more challenging.
For estimating in Story Points, the team can implement Planning Poker sessions in refinement meetings during the course of the sprint or at the Sprint Planning. Planning Poker is a consensus-based estimating procedure that is commonly used by teams to estimate backlogs. For more information on Planning Poker, check out this article.
Pros of using Story Points
- It ensures that the entire team is accountable for the estimation, making it more trustworthy.
- It eliminates Time Ticking, which can be pretty stressful.
- The task is given an estimate that is independent from the developer expected to implement it. This makes it a one for all and all for one approach to task estimation.
- Once the team is familiar with the method and has good reference stories, it can estimate a lot of Stories in a short period of time.
Cons of using Story Points
- It is not a very transparent means of task estimation.
- It takes a few sprints for the team to be satisfactory with Story Points, estimating and predicting the development team’s capacity.
Do not map Story Points to Hours.
Hours are a measure of time and Story Points are a measure of size. They should not be mapped as time depends on various factors, the more obvious one being the experience and seniority of the person doing the task. On the other hand, the team can agree on the complexity or size of a Story regardless of their experience.
Let me give you an example:
Imagine two runners. Runner A is very experienced and runner B started two months ago with the goal to lose weight. They both just finished a 2 Km trail. Runner A completed it in 20 minutes, and Runner B finished the trail in 60 minutes.
Now imagine that you present both runners with a new 4 Km long trail. Both will have an idea of how long it will take them to complete this new trail, and the time estimations will surely differ. But something in which both will agree on is that this new trail is twice as long as the previous one.
In scrum, the team is the one who estimates instead of the runner. To be successful, the team should establish a common metric. This should be one that they agree on as far as the size and measure of a Story is concerned, and one that can be translated to the work they finish in a sprint.
Conclusion
Creating software is not a mechanical task. There are multiple factors that can affect the duration of the work. Also, clock ticking can be very stressful when you are committed to a project, as well as frustrating for the team and the team’s management.
To summarize, scrum teams have to be accountable for the work they are completing, while utilizing a strategy with fewer errors to estimate, generating trust within the team and delivering value with the Story Points.
We think and we do!
Do you have a business that requires an efficient and powerful data architecture to succeed? Looking for a software development agency to make it happen? Get in touch with us at White Prompt today!
