I am a Product Marketer at Atlassian and an agile enthusiast. I am passionate about continuous improvement and helping teams work better together. Before starting at Atlassian, I was responsible for leading agile adoption and transformation efforts across Marketing teams at the world's largest children's healthcare charity.
We know that estimation is HARD. It's an ongoing challenge to reliably predict when a team will deliver software so we’ve joined up leaders in the industry to unpack story points and the evolution of agile estimation.
Estimation using story points has become the most popular way for agile teams to rate the relative effort of work, instead of using traditional time-based estimates. Unfortunately, story points are often misused. Sometimes, story points even encourage agile anti-patterns!
To improve estimation practices and avoid the pitfalls of story points, I hosted a round table discussion with Mike Cohn, John Cutler, Andrea Fryrear, Troy Magennis, and Dave West.
Read on for a short summary of key takeaways and watch the full discussion for a comprehensive view of how story points fare in modern agile teams.
What are story points and where did they come from?
Story points are units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other piece of work. Teams assign story points to work, relative to work complexity, the amount of work, and risk or uncertainty. Values are assigned to more effectively break down work into smaller pieces, so they can address uncertainty. Over time, this helps teams understand how much they can achieve in a period of time and builds consensus and commitment to the solution. Story points are generally credited to XP (Extreme Programming).
Story points go wrong when they’re used to judge people, assign detailed timelines and resources, and when they’re mistaken for a measure of productivity.
Story points are useless when teams default to filling them in, without considering the internal and external forces that might influence the work priorities. Teams need to focus more on the size of the work and the prioritization of the work, rather than treating story points as a bar to enforce and measure how much work is delivered.
Teams need to iterate on the estimation practices by promoting curiosity, hosting reviews of past estimates and how they achieved or missed their timelines, and aligning near-term tasks with the long-term goals of their project, team, and company.
Practical methods include:
Triangulation: Humans are much better at estimating relative size than absolute size. When teams use triangulation, they compare a user story they want to estimate with previously-estimated user stories. Then, they decide whether the current story is smaller, the same, or bigger than past stories.
Unpacking: Teams take a project of moderate size and break it down to list the sub-stories within it. They only identify the sub-stories but don't estimate them individually. Once they understand the sub-stories, they re-estimate the parent story. This has been shown to produce better estimates because the team has identified more information about the nature of the work.
Planning Poker: This technique reduces anchoring bias by asking teammates to use playing cards to submit their story points estimate. Cards are available for different values, and each person “plays” a card for their project. Once all team members have played their estimate card, they discuss the differences and align on the estimation.
Estimation units: This is a unit of measurement for relative sizing techniques. Many teams use T-shirt sizes (S, M, L, XL), but you can also use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, and so on). Teams also create their own units, such a gummy bears, NUTS, or foot-pounds.
Affinity estimation: This is a quick way for teams to visualize the product backlog into groupings of relative sizes. Affinity estimation leverages many types of relative scales, including T-shirt sizes (e.g. XS, S, M, L, XL, XXL), story points based on the Fibonacci sequence scale (e.g. 1, 2, 3, 5, 8, 13, 21...), or other scales (e.g. dog sizes, gummy bears).
Nesting Teams catalog many small things but ensure they don’t lose sight of the bigger picture and how all the elements fit together.
Taxonomy: The practice of teams co-designing a reference guide or “taxonomy of the work” helps break down what a team must know about the work to make good decisions and understand when work falls outside of that taxonomy.
Where do you land in the great debate of story points and estimation in agile? We'd love to hear your thoughts!
Mike Cohn is the founder of Mountain Goat Software and co-founder of the Scrum Alliance and the Agile Alliance. In addition to authoring three popular agile books (User Stories Applied, Agile Estimating and Planning, and Succeeding with Agile), Mike helps companies adopt and improve their use of agile processes and techniques to build high-performance development organizations.
John Cutler is the Head of Product Research & Education at Amplitude. As a former UX researcher at AppFolio, a product manager at Zendesk,Pendo.io, AdKeeper, and RichFX, a startup founder, and a product team coach, John has a perspective that spans individual roles, domains, and product.
Andrea Fryrear is a leading authority on Agile marketing. She is a co-founder of AgileSherpas and oversees training, coaching, and consulting efforts for enterprise Agile marketing transformations. Andrea co-authors of the ICAgile Marketing Agility curriculum and has written two books on marketing agility: Mastering Marketing Agility and Death of a Marketer.
Troy Magennis has helped deliver valuable software to customers at scale for over 25 years. In 2011 Troy founded Focused Objective, a leader in Agile metrics and probabilistic forecasting. Eager to share his passion for using data in better ways to improve business outcomes, he regularly keynotes, consults, and trains organizations wanting to improve decision making for IT through Agile and Lean thinking and tools.
Dave West is the Product Owner and CEO at Scrum.org. He is a frequent keynote speaker and is a widely published author of articles, along with his acclaimed book: Head First Object-Oriented Analysis and Design. He led the development of the Rational Unified Process (RUP) and then worked with Ivar Jacobson running the North American business for IJI, managed the software delivery practice at Forrester research, and was Chief Product Officer at Tasktop.
Kelly Drozd (me!) I am a Product Marketer at Atlassian and an agile enthusiast. I am passionate about continuous improvement and helping teams work better together. Before starting at Atlassian, I was responsible for leading agile adoption and transformation efforts across Marketing teams at the world's largest children's healthcare charity.