At first, the concept of a “point” is awkward and obscure, but as the team evolves, points become a very efficient way of estimating how much work can be done by the team. When implemented correctly, story points improve efficiency, are a good tool for estimation, and help the team become self-organizing and accountable.
Although modern thinking preaches that it’s impossible to estimate, I used to do it all the time. For over a decade, I ran a consulting firm that created very accurate estimates. The downside is that it’s very difficult to master estimation, so it’s become somewhat of a lost art. All sorts of issues crop up in typical companies that make all aspects of estimation difficult. Even if you can estimate the time it will take to complete the work, you may not be able to estimate how much time your staff will be able to dedicate to completing the task.
Definitions:
Story Points: In Agile methodologies, particularly Scrum, a “story point” is a unit used to estimate the amount of work required to implement a given story, feature, or piece of functionality. Story points are abstract measurements that allow development teams to understand the relative complexity of tasks compared to each other.
Sprint Velocity: In Agile, sprint velocity refers to the average amount of work a team can complete during a sprint. It is calculated by summing the total number of story points (or any other unit of measurement the team uses for estimating effort) completed in a sprint and then taking an average over a certain number of sprints. This average then becomes the team’s velocity. For example, if a team completes 50 story points in the first sprint, 60 in the second, and 40 in the third, the team’s velocity is (50+60+40)/3 = 50 story points per sprint.
Epics: In Agile methodology, an epic is a sizable body of work that can be broken down into smaller tasks or stories. Epics are often used to group multiple related user stories and contribute to a common, high-level feature or objective. For example, if you are developing a mobile application, an epic could be “User Authentication,” which would then be broken down into smaller user stories such as:
o “As a user, I want to be able to register.”
o “As a user, I want to be able to log in.”
o And “As a user, I want to be able to reset my password.”
Epics help organize the work and can be useful for tracking progress on a larger scale. They are often used in the product backlog to capture coarse-grained requirements that will be refined into more detailed user stories as the work progresses.
Roadmaps: An Agile roadmap is a high-level visual summary that maps out the vision and direction of a product offering. Unlike traditional roadmaps, which often contain fixed features and dates, an Agile roadmap is flexible and adaptable to change.
Suck -----------|-----------|----------|--------- Awesome
Suck: Using hours instead of points.
Good: Using points but not really understanding the components of a point.
Awesome: Using points and being able to accurately estimate how much work can be completed within a sprint.
How to Use Points When Estimating How Much Work Can Be Done
How to Conceptualize Points
A useful analogy for understanding points is taught in the ScrumMaster class by Mike Cohn. Imagine listing ten animals, ranging from a mouse to an elephant. It’s clear that a mouse is the smallest, and an elephant is the largest. Similarly, with points, a mouse could represent the smallest unit (1 point), whereas an elephant could represent the largest (40 points).
Therefore, an animal larger than a mouse but smaller than an elephant, like a bear, might be assigned 20 points, while a cat could be 5 points. This is an example of relative sizing, where the size or effort of tasks is compared relative to each other, rather than being measured in absolute terms.
Components of a Point
In software development, points embody the following three components:
Effort: This is the amount of work required to complete a task or a user story. It includes not only the time needed to code but also test and document a feature. Teams may have additional requirements, such as compliance review. Anyone’s effort that is required to complete a story should be considered.
Complexity: This measures how complicated a task or a user story is. A task may not require much time or effort but can still be complex and, therefore, receive a higher story point value.
Risk or Uncertainty: This accounts for the unknowns, or the uncertainties, associated with a task or user story. A task that has a lot of unknowns or is deemed risky may be assigned a higher story point value to account for the additional effort that may be required to address these unknowns.
What a Point Isn’t
A point isn’t a precise measure of time.
WARNING! A common mistake I see new teams make is they use hours as a measure for points. Resist the temptation to tie points to hours. If, for some reason, hours need to be tracked, do that independently. If hours are directly tied to points, many of the advantages of points (described later in the article) are forfeited.
When You Should Avoid Points
There are some cases where you don’t want to use points, such as:
When spiking totally unknown items that have all the signs of becoming a complete time suck. For cases like this, I would recommend tasking the story in half-day increments. If you timebox the story, it won’t consume the whole sprint. So, how do you account for this in velocity? I know I just warned about tying points to hours, but to keep all the reporting functioning, some point estimation will have to also be given. When discussing with the team, I recommend taking the following approach to estimating SPIKE with a very high level of uncertainty.
First – set points for the ticket.
Second – put a limit on the time spent working on the ticket.
When estimating epics, I would recommend using T-shirt sizes of extra small (XS), small (S), Medium (M), Large (L), and extra-large (XL). (I will write a blog on this later.)
What to do if your boss wants dependency trees, project plans, and hour estimates? If getting a new boss isn’t an option :), a couple of approaches may help with these sorts of requests.
Educate your boss on Scrum. Start with having them attend a standup. Let the team know ahead of time that a guest will be attending. Let your boss know that these meetings are meant to be very, very efficient, so no talking is allowed on his part. It would be best if the team executed the standup optimally, taking less than 15 minutes.
Ask for three months to prove Agile works by demonstrating your execution.
Attempt to explain progress through the traditional Agile concepts. For example, a project roadmap could be created containing all the known epics.
Why Do Points Work in Agile?
Quick and Easy Implementation: Relative sizing with story points facilitates an easier categorization of work, making it a fast and simple method to implement.
Promotes Team Discussions: The estimation process encourages discussions about the work, helping the team better understand what needs to be accomplished.
Ensures Consistency: Using story points promotes consistency in the estimation process across different tasks and sprints.
Accounts for Real-World Overheads: Recognizing that people have other daily tasks and overheads, story points allow for a more realistic estimation of the work that can be done in a given time frame.
Makes Work Understandable: Estimating stories helps break down the work into manageable and understandable chunks.
Minimizes Time-Related Conflicts: Story points reduce disputes over small amounts of time, avoiding situations where team members argue over whether a task will take one hour or two.
Facilitates Learning to Estimate: Using story points helps all team members, regardless of their role, learn and improve their estimation skills.
Encourages Regular Practice: Teams that use story points regularly tend to improve their estimation skills over time.
Self-Regulating: If a team underestimates a task, they are likely to adjust and improve their estimations in the future. Additionally, the point estimate will naturally decrease over time as a team becomes more proficient in a common task.
By incorporating these aspects, story points prove to be a beneficial tool in Agile, promoting effective conversations, consistency, and continuous improvement in the estimation process.
How to Explain WTF Is a Point to Members Outside of the Team
Relative Measure: Story points represent the relative effort needed to complete one story compared to another. It’s not about the absolute time but about comparison.
Consideration of Multiple Factors: Estimating with story points involves considering various factors, not just the time a task will take. These factors can include the task’s complexity, the amount of unknowns, and the potential risk or effort of any dependencies.
Common Scales: Teams typically use specific scales to assign story points. Commonly used scales include the Fibonacci sequence (1, 2, 3, 5, 8, 13, …) and powers of 2 (1, 2, 4, 8, 16, …). The idea behind this is that as numbers get larger, the precision of estimation decreases.
Consensus-Based Estimation: Teams often use techniques like “planning poker,” where each team member provides their estimate separately. After revealing their estimates, the team discusses the differences and comes to a consensus.
No Direct Conversion to Time: It’s essential to understand that a story point is not a fixed amount of time. For instance, one team might complete 20 story points in a sprint, while another group might complete 10. Each team’s point is specific to their context, making them useful for intra-team comparisons and predictions but not necessarily for inter-team comparisons.
Velocity: Over time, a team will develop an average number of story points they complete in a sprint, known as their “velocity.” It can be used for forecasting future work but should be understood as a guide, not a commitment.
Refinement and Adjustments: As teams continue to work, they often revisit their story point definitions and make refinements. The goal is always to improve estimation accuracy and predictability.
Conclusion
It is universally accepted that planning is crucial for accomplishing work. A key element of planning involves understanding the effort, complexity, and uncertainty associated with tasks. Over the years, various complicated, difficult-to-master, and inefficient estimation techniques have been attempted. Story points, however, offer not only a pragmatic tool for estimation but also facilitate the team in several other aspects, including understanding the work, enhancing communication, and mastering team collaboration.
Comments