Essential points about Story points (that are too often overlooked)

[#1]

In this article we're going to talk about story points that were introduced in Extreme Programming (XP) software development by Kent Beck (1) and Ron Jeffries (2). Nowadays, story points have evolved into a means to get a grasp on the complexity and size of work items when working according to the Scrum Framework. Project teams are in charge of assigning story points themselves and they use them to compile a list of work items that they commit to finish in a dedicated period (sprint).

At first glance

• Starting with story points
  When a team first starts to work with story points, they start without a reference to measure the size and complexity of their work items. The process is often called planning poker(3), where each team member reveals the number of story points that they think is fair to be given to a work item. When all points are on the table, the team establishes consensus by discussing the differences, coming to an arbitrary story point base value for a specific work item. Only by repeating and evaluating this process, the team memorizes their story point base for typical reference work items that are "worth" X, Y or Z story points. To help the team in this, it is best to start them off with work items that are roughly of similar size and complexity.
• Over time, team members grow more proficient in assigning story points to work items. It allows them to think out-of-the-box and provide rough estimates of other types and quantities of work. Fibonacci's numbers ( (1), 1, 2, 3, 5, 8, 13, 21) are used in planning poker, to help reaching consensus while estimating larger chunks of work(4).

Usage conditions

Scoring story points for new work items makes use of a team's story point base value for well-known work items. This means that a single work item is prone to be scored differently when allowing two teams to score it for story points. Both teams might have a different team consensus on evaluating the size and complexity of work items, leading to these differences in story points given. In essence, story points are a team specific characteristic. As a result, anyone adding story points of different teams together is misusing them because they are adding apples to pears. Needless to say, the added value of such calculations may vary.

The above highlights on story points are however only the tip of the proverbial iceberg. To safely navigate the surrounding waters, one would need to know how internal and external changes can throw a (temporary) spanner in the works.

Team changes

As a result of the "organically grown, team-specific" story point reference knowledge, any changes to the team itself can potentially wreck this characteristic story point base value that the team uses to estimate the story points of future work items.

Addition of new people to the team

• Onboarding new members takes time and effort: expect work item throughput to dip first. Depending on the knowledge of a new team member, work items may very well take a different amount of time to process. Expect new junior team members to require some level of support in their onboarding by a more senior team member. Such support would temporarily impact the general story point throughput of the team.
• New team members also take part in the planning poker process to establish the number of story points for new work items. Their input will influence the outcome, thus adjusting the team story point base reference value.

Exchange of people between teams

• Mixing people from two teams to improve throughput.
  It is perfectly justifiable to use the expertise of a member of team A to enhance expertise of a second team (B) by transferring this person to Team B. However, in the same manner as outlined above, this can modify the characteristic story point base value of both team A and B. Depending on the respective team memory and the expertise match between the person and the receiving team, exchange of people between teams generally leads to new throughputs and new story point base reference values for the two teams.

Environmental changes

• Shift towards new or unfamiliar work items
  A shift in the work item backlog of a team towards unfamiliar work could introduce a period of renewed calibration of the team story point base value. As the team gets more familiar with the new type of work items, they can pin a more realistic story point value to these new work items.

The role of the scrum master

The major task of a scrum master is to help the team grow in terms of efficiency, knowledge and predictability of its throughput. A scrum master helps starting teams find their own story point base reference value. Likewise, a scrum master can play a stimulating role in normalizing story point base values across multiple teams. The goal of this harmonization should be the breaking down of barriers between teams by providing them more of a common ground to work together. It should never be used to compare, evaluate or score the achievements of teams.

Jira and story points

Strangely enough, story points in Jira are generalized. There is no such thing as team-specific story point reference values in Jira. This means that we, as users of the Jira software environment, should be aware of the fact that story point values can/will have a different meaning for different teams. This is especially true when data from different teams is combined in:

• Plans (roadmap views) for high level management across different teams
  Plans can be used by management to obtain the critical path in the production chain, visible in the Gantt chart as the back-to-back planning of consecutive work-items start and finish dates. They can calculate different scenarios using virtual teams with their own story point throughput. The outcome and value of these scenario studies depends greatly on the understanding of the essential points about story points described in this article.
• Boards that combine Jira work items from different teams
  When complex work is shared between teams, a correct prognosis of their total throughput can by tricky as this depends greatly on the story point definition of the participating teams. Generally, it is wise to reserve some extra capacity to compensate for any large discrepancies or to make an effort to normalize story point input.

Conclusion

When it comes to story points, their summation is only guaranteed to be valid within the scope of the defining team. When story points originate from different teams, one plus one can be two, but this outcome is not guaranteed to have significance. To properly know how to handle addition of story points in this situation, one should always take into account their associated meaning to the teams from where they originate.

References

1 Kent Beck Extreme Programming Explained: Embrace Change (Addison Wesley, 2003)
2 Ron Jeffries Story points revisited (Personal website, 2019)
3 Mike Cohn Planning Poker: an Agile Estimating and planning technique (Mountain Goat Software Website)
4 Mike Cohn Why the Fibonacci sequence works well for estimating (Mountain Goat Software Website)

Acknowledgements

A big thank you goes to @Kit Friend for providing additional depth.

[Bill Sheboy]

Hi @Dick 

Thanks for your article...and particularly for including the updated information from Ron Jeffries as his ideas have evolved over time for use of this practice / tool.  (As have Kent Beck's based on his recent writings around "Tidy First?" concepts.)

In my experience, story points are one of the "training wheel" concepts for agile teams.  This practice helps a team safely experiment and improve their abilities to form shared understanding and to split work into more like-sized valuable chunks...eventually reaching the point where sizing and estimation are no longer needed.  Instead the team may just count work items to help with planning and forecasting.

Until that maturity is reached, some things I have found to help (some of which are described in the sources you linked) include:

• Understanding and knowing when to use Affinity Sizing, Planning Poker, and Triangulation
  • Affinity Sizing -- start with an empty wall, put S / M / L coarse sizes at the top, put the first work item in the middle, team silently adds all the others (relative to the first), team discusses and adjusts, and finally maps numeric sizing (i.e., story points) to the columns.  This helps at the start of a larger effort and during team formation activities.
  • Planning Poker -- as you have described above, for established team / work method situations
  • Triangulation -- used with either of the above, playing "which of these things is not like the others" (or is like), by comparing work items in different sizing columns, helping to challenge and confirm shared understanding and assumptions, with the team and product owner / champion
• Once the team has a shared understanding of sizing (e.g., what does "3" mean to us), a tool that helps is a Sizing Ruler
  • Identify comparable work the team has completed in the past, and use it to create a simple memory tool to both speed the sizing part and validate understanding
  • Regularly use to recoup the value
  • Periodically update the ruler, based upon changes in team membership / skill / experience, work domain area, tooling, process, etc.

Kind regards,
Bill

[Dick]

Thank you @Bill Sheboy for sharing your knowledge regarding the additional ways that  maturing teams can use to size and plan. It is greatly appreciated. Three is the magic number (the holy trinity). 

Kind regards,

Dick