“Prediction is very difficult, especially if it's about the future!”
Niels Bohr, Nobel laureate in Physics
Do you know the story of Sagrada Familia – the famous cathedral in Barcelona? It’s the most renowned unfinished project in the world, whose construction started in 1882 and whose completion date has been postponed many times due to wars, vandalism, pandemic, and so on. Today, it’s in the final stage, but still nobody knows when it’s going to be completed. A similar story happened to the Sydney Opera House in Sydney, Australia. It was finished 10 years later than planned and cost $102 million instead of the initial budget of $7 million.
Those are examples of inaccurate estimation. Basically, estimation is the same as guessing and trying to take all the related factors into account. We do it all the time: struggling to figure out our vacation budget, planning food and drinks for a party, or determining our ETA considering traffic to know if we’re going to be late for dinner.
In software development, estimates have to be done to evaluate the duration and cost of the project. And understandably, stakeholders want them to be as accurate and reliable as possible. But how can this accuracy be achieved?
To effectively estimate tasks, there’s a special unit of measurement. In this article, we’ll talk about the concept of story points in Agile development, figure out how to calculate them, and explain what poker has to do with that.
What are story points?
Story points (SPs) are relative units that measure how much effort is needed to complete a certain task. They consider three main factors:
- amount of work,
- complexity, and
- risks or uncertainty.
It’s important to understand that estimates are not commitments or final answers. They are assumptions with a certain degree of uncertainty and can be updated throughout the project.
SPs are believed to have been invented by Ron Jeffries, one of the founders of Extreme Programming. They were popularized by Mike Cohn in his book Agile Estimating and Planning published back in 2005.
With time, they became a common metric in Scrum and other Agile methodologies and in many cases replaced estimations in time or money. In this post, we’ll focus on Scrum as that’s what SPs are typically related with (even though they’re not a part of a Scrum Guide. Moreover, the latest 2020 Scrum Guide doesn’t even mention estimates, shifting the focus to project outcomes).
Story points have their pros and cons, but before discussing those, let’s explain how estimations are made.
How to calculate story points in Agile? Fibonacci story points and Planning Poker
Typically, SPs are applied to user stories, which are the descriptions of a product’s functionality from a user’s standpoint. User stories, the smallest units of work in Scrum, are collected (often from a product requirements document) and managed by a product owner during sprint planning and backlog grooming. For example, a user story may sound like:
“As a customer, I want to add a credit card to my profile” or
“As an app user, I want to receive email notifications about new messages.”
The most popular estimating technique to calculate SPs is planning poker.
Planning poker is basically voting with cards that have Fibonacci sequence numbers on them. In Agile, the Fibonacci sequence is usually modified to 1, 2, 3, 5, 8, 13, 20, 40, and 100 (watch Mike Cohn explaining how and why that happened). Sometimes, cards with 0, ½, ∞, ?, and other symbols can be included.
You can also use t-shirt sizes (S, M, L, XL) or make up your own units (dogs, Pokemons, chocolate bars, or whatever else comes to mind).
A deck of cards for playing poker. Source: Wikipedia
As we mentioned, SPs are relative units, so a baseline or a standard has to be set up that you’ll compare your user stories to. For example, you can agree that 1 is a simple task that takes less than 2 hours to complete and holds no risks (like adding a text field to a page).
Mike Cohn advises choosing two values that everyone agrees on (like 1 and 3 or 2 and 5). Relating to two pre-set values will make it easier for team members to make estimates. You can also create a matrix to visualize your story points.
An example of a story point matrix
So here’s how planning poker is done.
Step 1. Team members get together and everyone gets a set of cards. In case you work with a distributed team, there are a number of online planning poker tools, such as Planning Poker or Planning Poker Online.
Step 2. Then, a product owner reads a user story from a sprint backlog and the team discusses it briefly.
Step 3. After the discussion, each team member privately selects a card that in his/her opinion best represents the estimate. As we said earlier, the amount of work (including QA activities and overheads), its complexity, and related risks or uncertainties have to be considered when deciding on the estimate.
Tip: When choosing the card, you can think of user stories as buckets that you fill with sand. You can probably squeeze 9 units of sand in an 8-unit bucket, but if it’s more, you’ll have to take a bigger one.
Step 4. Once everyone is ready with the card selection, cards are revealed simultaneously.
- If the numbers on the cards are the same, you’ve got the estimate and can move on to another backlog item.
- If the numbers are different, the discussion and voting are done again, until the consensus is reached.
An example of planning poker estimation results. Source: Mike Cohn
Sometimes, the range of estimates is too big, like 2 to 100. That might happen because of uncertainties about the product itself or the technical solution of the task. In this case, it’s better to postpone the voting on this item until the product owner has more information.
When discussing the user story or estimations, it’s important to encourage team members to express their opinion since they can have different perspectives due to different previous experiences. Such discussions are of great value as they allow everyone to get on the same page on what they’re doing.
Well, you’ve got your estimates. Now, you have to track the project’s progress and the team’s performance. For this purpose, sprint velocity is measured.
How to calculate sprint velocity?
Sprint velocity in Scrum is the amount of work done during a sprint. It’s a measure of the team’s productivity since it shows the number of backlog items successfully delivered in an iteration.
To calculate the velocity, just add up all the story points of the completed stories. As simple as that.
It might be complicated to estimate the first several sprints of a project, and your velocity will probably fluctuate. However, as the team works on the project and gets better at estimations, velocity is going to stabilize and will be roughly the same from sprint to sprint. It’s important to track it as it gives the product owner and other stakeholders an idea of the project duration.
An example of a velocity chart to track velocity
N.B. Don’t expect your velocity to increase since it’s not realistic and would mean extra workload for your workers. In some cases, you might even choose to decrease the average sprint velocity to focus on the quality of your deliverables.
Story points vs hours: Why use story points?
Okay, so now we got to the most popular question: Why the heck use those weird, abstract units if we can simply measure our work in man-hours?
Well, that’s true, time has always been a traditional format to estimate workloads. Hours or days are easy to understand, but still, there are a few downsides to such an approach that SPs don’t have.
Time calculations correlate with the seniority of the programmer (an experienced engineer can code faster than a junior dev) while story points are universal and relative, objectively measuring the task complexity. So, one story is always X times bigger than the reference one, no matter who’s going to handle it. It’s especially important if team members change during the project.
Time format only considers the actual coding hours while story points are more flexible and include the entire workflow with all the additional activities like meetings, emails, etc.
Time estimates are often prone to planning fallacy and anchoring effects when people tend to underestimate possible difficulties or decisions are biased by different factors. The abstraction nature of story points helps avoid the bias.
“Unfortunately, stakeholders often don’t realize that estimates are approximate and tend to take them as commitments,” Ivan Petruk, a PM at AltexSoft, shares. It especially concerns time units. Story points don’t generate such erroneous assertions and aren't taken as a pledge.
SPs are also a good way to see risks and identify team members that didn’t understand the user story and the task behind it.
There’s one more consideration. Group estimates are better than individual estimates. Planning poker supports discussions and collaboration since the entire team participates and determines the final estimate. And it’s good in terms of team building too.
Remember that time… well, it’s only time, as blunt and straightforward as your customers’ reviews. SPs that measure effort, which is a knotted combination of factors, offer a more holistic picture.
Problems of story points
Don’t think that SPs are a panacea and will magically solve all your estimation issues. They have their flaws as well.
Story points are often misunderstood and misused
The first snag lies on the surface: Story points are imaginary units and are barely understood by stakeholders (and a lot of programmers as well, actually). Your customer wants to know when the work will be done as precisely as possible and doesn’t really care how much effort it’s worth. So you end up converting one scale to another, usually without much success.
Since they are frequently misunderstood (by all the parties involved), story points are often misused. For example, managers tend to compare teams by their velocity, which is a false choice since different teams would give different values to their story points. Or estimates can get inflated if the management focuses too much on velocity instead of value.
Possible solution: Make sure everybody clearly understands the SP concept, including stakeholders, and measure your project in sprints. That will give all participants the idea of its duration.
Story points don’t work with tasks involving new technology
Next, story points aren’t the best fit for projects in which the team encounters technology they never dealt with before. Ivan Petruk admits, “If the team has no idea about how to approach the task, any estimates would just be guesswork”.
Possible solution: Postpone this user story to the next sprint until the team gathers more information about the unfamiliar task.
Planning poker can go wrong
Another problem is that planning poker might not be as fun and accurate as it might seem. Sometimes too much time is wasted on discussions and trying to reach that essential consensus. And then, even if it’s achieved, the estimate isn’t necessarily exact since the whole team might be wrong with the assessment.
Possible solution: A product owner has to act as a moderator and either limit the discussion time or help find a compromise.
Story points do not account for value
Also, story points do not represent value; they only embody the effort. It’s not only their weakness, but you still have to realize that the story with a high estimate will not necessarily be the most valuable and vice versa.
Possible solution: Prioritize backlog items in advance and don’t associate them with SPs.
Story points can’t show the estimate accuracy
Lastly, it’s hard to use story points to measure the estimate accuracy. Sviatoslav Laha, another AltexSoft PM, indicates, “The team can give the same values to separate backlog items, but spend different time completing them. So, you can’t evaluate how accurate the initial estimate is.”
Possible solution: Don’t use SPs in projects with a focus on strictly meeting deadlines.
Story points best practices
The choice whether to use SPs to make estimations or not is definitely yours. But if you decide to give this approach a chance, here are a few more tips for you.
Split large user stories. If you regularly get big numbers during playing poker (anything greater than 8), it might mean that your user stories are too big (or your team is trying to “game the system” and intentionally blows up estimates to increase velocity). Try breaking such epics up into smaller, more digestible pieces and re-estimate.
Learn from previous estimates. You can use project management software like Jira or other tools like Kanban boards to track your story points. Get back to your past estimations occasionally and discuss with your team how accurate they were and why you had discrepancies (if any). Use these insights to improve future estimations.
Don’t mix story points with time. It can be tempting to convert points to hours, but that’ll kill the whole idea. If you need a time estimate, measure average sprint velocity and calculate the number of sprints necessary.
Set values regardless of who is going to perform the task. It’s clear that senior developers will cope with tasks faster and easier than juniors, but the point of story points (sorry for the tautology) is to objectively estimate team effort. Besides, sometimes roles might change during the sprint.
Use the same reference value in every sprint. If you take a different one every time, velocity can no longer be compared. So it’s better to use previous references.
Make rough estimates for future items. A lot can change by the time you get to user stories deeper in the backlog, so there’s no point in estimating them in the beginning of the project. Give your product owner or project manager rough figures and get back to them later on. For more information, check our post about rough order of magnitude.
Practice. That’s the single most important piece of advice. It’s okay if your estimates aren’t accurate at first. Practice makes perfect and experience counts, you know. You’ll be doing better every time, just like you are at planning your vacation or parties. :-)
Experts’ opinion on whether to use story points or not
Roy Jeffries once wrote, “I may have invented story points, and if I did, I’m sorry now.” In the same post, he laments that SPs are frequently misused and advises focusing on slicing tasks and continuously delivering value instead of making estimates, whether in SPs or not (you can check his or other articles on the #NoEstimates movement). In the end he admits, “If I did invent story points, I’m probably a little sorry now, but not very sorry.”
Eugene Ovdiyuk, an AltexSoft PM, recalls his own experience: “If the team is small, team members aren’t interchangeable, and there’s a number of diverse tasks, then story points just won’t work and it’s definitely better to use hours. And if the team is large and cross-functional, then estimating in hours takes a lot of time and it’s worth choosing story points. I could plan a year using story points with a deviation of less than 1 percent and the sprint itself with an error of 10 percent.”
Bottom line, if it works for you – great. If not – there are other options like estimating in hours/days or not estimating at all. It’s like driving a car with a manual transmission: It might not be the best fit for everyone and it takes a bit of practice, but once you master it, it can show best results in a race.