Capturing a user story is a vital part of project management. Let us introduce story points – the heroes of this approach.
Start with a why
Before we focus on story points, let’s take a moment to introduce the tool used in Agile software development. The programming process is carried out by completing tasks, which are often described by user stories.
User stories answer who, why, and how questions in the context of software requirements. They’re not stories in the common understanding, long and detailed. Usually fitting onto index cards, post-it notes, or in tabs of dedicated software, user stories are clear and concise.
Software development projects need estimations to answer inevitable questions, emerging on the clients’ side – how long will it take, how much will it cost, how many programmers will I need?
Once we know the hows and whys, we divide the project into tasks to be done, and that’s where story points enter the stage.
Story points – what are they and where do they come from?
In project management, story points are a metric used to estimate the difficulty and complexity of implementing given requirements. The approach originated from the Extreme Programming methodology and became successfully adopted by Agile professionals.
The size of stories is not estimated in hours, days, or weeks of development, but story points (SP). For instance, a story with 1 SP is smaller than the one with 3 SP.
This estimation doesn’t indicate however the time necessary for the delivery of the desired result.
And we can’t stress that enough.
It’s a common project mistake to convert story-pointed tasks into hours. We strongly discourage this because story points do not translate directly into spent time. Story points are meant to reflect the dependencies and complexity of project tasks, not bare man-hours spent. As such, they present a more realistic prediction of the effort necessary to deliver tasks and projects. Story points are an answer to clients demanding fast/good/cheap execution of their projects. Most cases happen to be rather fast and good (or good and cheap) than all 3 at once. This approach puts more emphasis on delivering quality, not cutting costs by all means.
Story points indicate the complexity of upcoming tasks.
The focus during estimation should be on:
The volume
How much work and effort will be required?
The complexity of the issue
Is the item more complex than tasks of similar volume? Does it entail special handling (highly specialized knowledge, uncommon practices)?
Potential risks
Are there any identified unknowns and uncertainties? If so, are they addressed by managers prior to the project launch?
Team’s proficiency
How experienced are the team members in fields necessary for the projects’ execution?
Dependence on external parties
What necessary areas need to be addressed on the client’s side, e.g. APIs structure?
Do story points give clear answers?
Story points do not indicate expected costs or delivery dates, and as such, are considered by some to be problematic. While the approach itself doesn’t illustrate costs in a linear way, once project teams work out SP estimations, another metric can be used as a guideline.
Velocity allows estimating the cost of developing a certain number of story points per sprint. Describing what the team can deliver within a specified time, velocity reflects the number of story points delivered in each sprint. Keeping it in mind prevents project managers from packing sprints to the full with critical issues, leaving a buffer instead. This way, aside from focusing on core tasks, developers can use the potential spare time to include additional commitments and focus on technical maintenance, improvements, or paying the technical debt, once priorities are completed, but without the pressure to complete all tasks in unrealistic estimation.
Velocity reminds managers of dropping the default value of full 40 hours per developer weekly, as story points take into account all aspects not necessarily covered in time estimations. Breaks, daily meetings, and retrospectives aren’t coding, but all make up for developers’ working day, affecting the end result.
Issue:
Using story points may cause developers to increase their estimates habitually, impeding the general assessment of projects’ scope.
Solution:
Measuring velocity enables managers to monitor the pace of work and assure the estimated values remain corresponding to delivered features.
Are story points useful?
Story points reduce planning time and help improve the team’s performance. They are precise enough to plan sprints ahead (since we know how many story points can be delivered per sprint), allowing time expectations management in future work.
The downside of story points is the occasional lack of an intermediary value between e.g. 3 and 5 story points. When the higher number is chosen, time and effort saved up in the buffer can be compensated by adding additional tasks at the end of the sprint. The necessary condition for such a solution is the initiative of both developers and PMs.
Story points eliminate the need for frequent re-assessment of estimates, acting towards under/overestimating in the general sense. Being more general than time evaluations, they allow including more uncertainty in task assessment and a greater unification between team members.
How to avoid mistakes using story points?
- Don’t translate story points into hours
- Don’t adjust story points to team members
- Reduce risk and uncertainty prior to estimating
- Assess incorrectly story pointed matters during retrospectives
- Keep velocity tracking and make sure it is stable or increasing
- Discuss story point value definition with the team and provide a common understanding
- Make sure that the client is aware of the value behind the story point estimation approach
Should you use story points?
There are plenty of reasons to support the idea of story points, and we can list the most compelling:
- Avoiding rigid deadlines
- Improving commitment
- Focusing on quality
- Improving adaptability
- Boosting performance
- Minimizing technical debt
To be fair, let’s not forget about the arguments against using story points:
- The estimation of spent effort is not equivalent to spent time
- The approach is unsuitable for short-term works, as it takes more time to work out estimations in story points
- Story points require more trust to the teams’ members from the management
- SPs take more time to convince clients to use this approach
Pros outweigh cons (it depends, however, but we’ll get to that in a moment), and if carried out with care, story points contribute greatly to project execution. As for convincing clients, we prefer the show, don’t tell method. Presenting how velocity reflects task delivery is more effective than just describing the approach. When it comes to persuasion, we present a trial estimation of story points and velocity, as clients are best convinced by seeing tangible results.
Still, SPs are not a miracle cure, and as such, sometimes aren’t the right approach to take. They are a tool, and as in the case of other utilities, it’s crucial to select the most suitable instruments for the project for its most beneficial execution and not the other way around.
Especially in projects limited in time (depending on e.g. timeliness imposed by clients’ obligations to third parties) and more on the short side, time estimations may be more beneficial. This counts also for minor projects, performed sometimes by solely one programmer. In such cases, the traditional approach to assessing tasks is sufficient.
How do we measure tasks in story points?
Our developer teams measure tasks together, yet secretly. This way, each team member can assign the most adequate value, based on their expertise. Developers often use the PlanITPoker app, an easy tool supporting the assessment process.
The final number can be later on voted as too high or too low if some ratings significantly differ from the average value. Estimates are built on the consensus and the entire group’s insights, and as such, are more accurate than evaluations based solely on time expenditure. Risks related to estimating story points decrease over time the team cooperates. Experience gathered in projects is proportional to a shared understanding of story points value and curated by the manager, helping developers each time misconceptions arise.
Story point values can be assigned as the example shows:
Story points 1: Low complexity, little time needed, no new functionalities
Adjustments, small bugs, minor refactors, small frontend changes.
Story points 2: Low complexity, new functionality
The lowest possible estimation to be given for new functionalities and default estimation for bug fixing.
Story points 3: Normal complexity, new functionality
Standard tasks related to new functionalities. No bigger uncertainties related to the ticket. Usually, both frontend and backend work is required.
Story points 5: High complexity, new functionality
Not as uncertain and complex as 8 but not as easy as 3.
Still, a regular ticket but requiring more work than 3.
Story points 8: High complexity, new functionality, new domain
There are a lot of new topics to be explored within the task, the amount of requirements is very high, or the dependencies within the system are high. 8 is the highest estimation possible to give before we split the ticket, so we should ensure that the investigation happens before and that all the uncertainties that were possible to resolve were covered.
Story points: higher – split into smaller tasks
The final judgment – should you use story points?
Maybe that’s not the answer you were looking for, but…it depends. We work with traditional estimations and story points, both serve our projects well. Unsurprisingly, the secret is recognizing when story points will be the most beneficial to work performed, and when time measurements are just fine. Just like the eternal rivalry between the waterfall and Agile methodologies, each approach has its pros and cons, and it’s our job to make the best of them according to the needs.
Are you looking for a digital partner to create your project with? Book your 1-hour free consultation to see if we’re the right match and learn more about the best approach to your ideas.
