What is the Point of Story Points?
There’s good reason why story points are a bit of a conundrum for many people.
For one thing, the scrum guide mentions estimation, but gives no reference to story points and how they can benefit a scrum team in their estimations.
The idea of shifting from estimating in actual hours and minutes, to estimating with random numbers that only team members understand, naturally leads to resistance and hesitation.
Lastly, how do you quantify value to the stakeholders with points when stakeholders are used to equating time to cost?
What are story points?
Before you can appreciate the worthiness of story points you need to understand what they are. So let’s start with the definition:
“Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.”
The keyword in this definition is estimate. The overall effort that would go into a story is a raw estimate of the team’s understanding of that story at that instance in time.
In other words, a story point is purely a number assigned to a product backlog item (PBI), which is in relation to the number assigned to another PBI.
For example, let’s say a team gives PBI “A” a story points estimate of 1 and PBI “B” a story points estimate of 2. By doing so, the team is indicating that PBI “B” will take twice as much effort as PBI “A” to complete.
Who Benefits from Story Points?
- The Product Owner: With a well-estimated backlog and a stable velocity, the Product Owner can plan well in advance for upcoming features and functionality, and thus advance the product roadmap and vision forward.
- The Development Team: Since story points are estimates, the development team doesn’t have to commit to a specific time needed to complete a story, but instead a normalized amount of time. In an Agile environment, this allows the development team to accommodate change and readjust when needed.
- The Stakeholders: The internal stakeholders are able to envision the product vision well in advance and thus communicate the product’s future to customers and clients alike, fulfilling client demands. On the flip-side, the external stakeholders benefit from this knowledge because it assures them that their demands are being met, which cements current and future investments in the product.
What determines how many story points?
The number of story points that are assigned to a PBI is based on 3 factors:
- The work to be done: Based on the story description, the team determines what effort is required to develop, test, and release a story that would contribute to the overall effort.
- The amount of complexity in a story: The more functionally or technically complex the story, the more work it will require to complete.
- The uncertainty: At the time of estimation, if there are certain elements of functionality that the PO is unclear of, or if the development team is unsure of how the story can be implemented, that uncertainty and how it will impact the overall effort would be taken into consideration.
How to estimate story points
The process used for estimating story points is fairly easy and can be broken down into 3 simple steps:
- Outline a base story: A base story is essentially the team’s reference story. For this, the team gets together and picks a PBI that is simple to implement, i.e. one that is relatively uncomplex and all components within the story are clear and concise. The team then assigns the PBI a story value.
- Relative Estimation: Once a base PBI is defined, that becomes the standard reference for the team. Now the team can begin estimating from a prioritized list of PBIs, plotting the stories higher or lower vs. the baseline by comparing the effort, complexity, and uncertainty of each one.
- To assign a value, the team can use the Fibonacci sequence. The Fibonacci sequence story point estimates of 1, 2, 3, 5, 8, 13, 21 and so on. This is more effective than using 1 to 10 as this implores the team to provide a relative estimate. Why? Because it’s easier to ask, “Is that a 5 or an 8?” vs. “Is that a 6 or a 7?” The Fibonacci sequence is one technique that can be employed. There are other techniques, which will be explored below.
- PBI Sizing: Once the team has the stories estimated, they can then size the PBIs by the story value. This will allow the team to maximize the output of the sprint by quickly closing easier stories first before moving on to the more complex ones.
Different techniques for assigning a story points value
A scrum team, at its own discretion, may choose any methodology it sees fit to story point PBIs as long as it’s efficient at doing so. Here are a few alternative techniques to the Fibonacci sequence that are commonly employed by high-performing scrum teams.
- Planning Poker: This is a consensus-based technique that is usually done with a deck of cards (with numbers inscribed on them).
The process starts with the Product Owner pulling out a story from the backlog and describing it to the team. After the team understands the intended outcome of the story, each member, in a round-robin fashion, displays a poker card that they feel best expresses the value of the story.
If all estimators select the same value, that becomes the estimate. If not, the estimators discuss their estimates. The high and low estimators share their reason, and once consensus is reached, that value is selected.
The benefit of this technique is that every voice is heard, thus fostering team camaraderie and ensuring overall buy-in.
- T-shirt Sizing: This technique is particularly useful where the PBIs are not too diverse and can be classified in relatively smaller categories. It is a faster technique compared to Planning Poker, as the team can decide to keep the sizes limited to S, M, L (Small, Medium and Large) PBIs. This way, the team can scan through a lot more items in a shorter period of time, with fewer people. It’s a great method for providing high-level estimates on stories right after the discovery.
- Affinity Mapping: In this technique, similar stories are grouped together. It is based on finding similarities in the estimated items. The team is asked to group them together from small groups to large. This method is mostly used on a visual board and works best with a small group of people and a relatively small number of items. The team members can assign estimation numbers to the different groups, based on consensus.
- The Bucket System: This is an interesting technique that is essentially the reverse of putting estimates to stories. Here, story points are considered as “buckets”, and are put flat on a physical or virtual board. A few stories are picked, read aloud, and points consensus is put in the appropriate buckets which act as references. If consensus cannot be reached between 2 stories or buckets, then the story is put in the larger bucket. Thereafter, the remaining stories are divided among all team members, and each member puts the story at hand in the appropriate bucket based on his/her understanding of the overall effort of the reference story.
This allows for a large number of stories to be estimated quickly by a large group of people. If a team member cannot estimate a story, it can be passed around or swapped.
When story points estimation should be done, and by whom
Typically, a highly-efficient scrum team sets aside a separate time in a sprint to do story points estimation. This is better known as Backlog Grooming or Backlog Refinement. It is usually 2 hours or less, for a 2-week sprint.
If more clarity is needed on the PBIs, then the team sets aside more time, known as Joint Application Design (JAD), where the team, or respective individuals, brainstorm on stories and clarify requirements or technical doubts that they may have. This is typically done to provide more accurate estimations.
As far as who participates in the estimation activity, the entire team is involved. However, most of the actual value assignment is usually performed by the development team. Moreover, there are areas of specialization between the development team members who are more suited than others to comprehend and correctly estimate a story.
The key advantages of story pointing
Now that you’re up to speed on what story points are all about, let’s delve into the advantages of story pointing:
- Estimation without a time commitment: Since story points represent a normalized distribution of time, they are a rough indication of a range of time that can possibly be taken to complete a unit of work. This might differ from team to team.
- For example, for team “A” 1 point could equal 4-6 hours, and for team “B” 1 point could equal 8-10 hours. Thus, a team member, without jumping into specific hours and minutes can give story points without committing to a specific time. This is key to being Agile, because as things change over the course of a project (requirements, dependencies, technical impediments) they can still adapt.
- Quick estimation: As story pointing is relative, this hastens the estimation process as the team has to compare and estimate from a reference story rather than estimate afresh.
- Accurate planning: Once a stable velocity is achieved by the team, the Product Owner can then plan the backlog in advance, knowing that the team will be able to produce X units of work in Y number of sprints.
- Embraces uncertainty: Things do and will change over the course of a project, but story points allow the team to embrace that change rather than fight it.
- Fosters harmony: The team will be estimating in a consensus-based environment, which will ensure that each voice is heard. This fosters harmony and respect amongst team members.
Some story pointing tips to keep in mind
- Tip 1: Don't equate story points to the number of hours. If a team does that, the benefit of using story points is lost.
- Tip 2: Estimate bugs. A bug represents work that the team needs to complete. It provides value to the shippable product, be it either in the current sprint or the next. Hence even bugs should be captured and story pointed separately, and not done as a part of the original story itself.
- Tip 3: Don’t average story points. A team with a stable velocity may sometimes decide to average story points, e.g. a team with 10 stories and a stable velocity of 30 story points may average out each story with 3 points to quicken the estimation process. This should not be done. It gives a false sense of accuracy both to the team and to the stakeholders.
- Tip 4: Don’t re-adjust story points at the end of a sprint. This is a common mistake many teams make. Once a story spills over into the next sprint, teams readjust story points to capture only the effort remaining in the story, e.g. an 8-point story is going to spill over into the next sprint. During the next sprint planning session, the team decides that it is now 3 story points based on the remaining effort and changes it accordingly before starting the sprint. By this activity, 5 points worth of effort is not captured and lost, which depicts a false sense of accuracy and contributes to an ambiguous velocity.
- Tip 5: Time-box Spikes. A spike is used to learn, investigate, and do research as well as perhaps deliver a PoC. A new story is created as a result of a spike, not a shippable product. Hence, it is best to time-box spikes to a certain number of hours rather than putting story points to spike stories.
- Tip 6: Don’t readjust story points within a sprint. Once a sprint starts, team members should not re-estimate inaccurate story points given to a PBI. The whole idea of normalization is to ultimately achieve a stable velocity with experience, and not with re-adjustments. Even if your story points are inaccurate, your team velocity will mirror the correct state at the end of the sprint, and thus, will be a learning experience to attempt better estimations in the sprint.
- Tip 7: Readjust the reference story if the team changes. Each team has a different way of functioning and different team dynamics. When the team composition changes, it is good practice to re-align your reference story, as different individuals with varied skillsets may have different opinions on what the estimation should be. Thus, re-alignment to the reference story is necessary.
To learn more about how story points can ensure efficiency, better productivity, and growth within team members, email us at sales@architech.ca.
