February 20, 2023. Marshall Guillory
I have observed a misconception in the agile community where the claim is made that certain agile frameworks, guidance, practices, or implemented methods, et cetera recommend normalizing story points across teams. I have not personally seen any competent consultant or coach doing this, but I suppose that the nuances can be deceiving and drive some misinterpretation and faulty recommendations. In this article, I will unpack the topic and claim as it is often made against the Scaled Agile Framework.
-Ron Jeffries, Story Points Revisited, May 2019
“Some approaches to “Agile” actually recommend normalizing story points across teams, in the name of easier planning. While this seems sensible enough on the surface, it’s too easy to fall into the trap of comparing teams, and, too often, organizations do that.”
Ron is correct about the nature of people, falling into one of the many traps of Taylorism, or reductionist mindset with regard to managing people and systems. Focusing only on outputs is dangerous without the larger vision and context, understanding of the desired outcomes.
Since every business is in the software business today we will continue this conversation in that context.
before we go too deep Let’s Learn about normalizing story points across teams
First, we are going to ask everyones favorite creepy AI, ChatSPCT to define the topic space for us. This way we can level on the bias of the machine for the purposes of this discussion and not my opinions and bias. A simple prompt:
ChatSPCT: What is normalizing story points across teams? Normalizing story points across teams refers to the process of making sure that the same story point values have the same meaning across different teams within an organization. Story points are a relative measure of the effort required to complete a specific task or user story in agile development. Different teams may use different criteria or scales to estimate story points, which can lead to inconsistencies in the overall estimation process. Normalizing story points involves establishing a common understanding of what a particular story point value represents, regardless of the team estimating it. This can be achieved through activities such as: 1. Establishing a standard set of reference stories or benchmarks that can be used to calibrate story point estimates across teams. 2. Ensuring that all teams use the same criteria and definitions for estimating story points. 3. Regularly reviewing and adjusting the story point scale to reflect changes in the organization's priorities or capacity. By normalizing story points across teams, organizations can improve their ability to plan and prioritize work effectively, while also reducing the risk of miscommunication and misunderstandings between teams.
I focused in on the part of the definition where I believe people are getting hung up on, “Normalizing story points involves establishing a common understanding of what a particular story point value represents, regardless of the team estimating it.”
Speaking for myself, I never teach teams to normalize story point baselines or estimates against a single reference set (or a single “small story” for every team in a network). Normalizing should only occur within a single team system. This is part of the teams working agreements [the teams operating model]. We as a team believe that this is a small story because…”[fill in the blank].” It doesn’t make sense to normalize across teams. Are ALL of the teams going to work on ALL of the items? Probably not.
Forcing teams to normalize outside of [or across teams] the team would destroy the desired “agile” independence of the team and the teamwork mindset and behavior that we desire in the social fabric of the organization. The manifesto says, “The best architectures, requirements, and designs emerge from self-organizing teams.” If a manager or a coach dictates that all the teams must use xyz reference stories for the basis of estimating then the independence of self-organizing teams is destroyed. Agile estimating is a team art and science that is very much so unique to a particular team.
This is why we do not compare velocity of one unique team [of unique individuals] to another – whether it be in terms of raw flow, the number of items produced over a period of time, or of story points. I speculate that this anti-pattern in agile is a legacy of manufacturing production lines and measuring outputs.
In any given country, business, family, value stream network, tribe, ART, team of teams, football team, or agile team there is immense value in the [social] network agreeing on common communication paradigms and language. This is generally accepted practice across the world spanning all social and organizational structures.
SAFe, for example, introduces guidance for common language for teams using a standard process and modified Fibonacci sequence for relative estimating with Story Points, but each team still retains its own unique reference set for baselines (e.g. this story is a “1”). At scale, this enables a Capacity Allocation Guardrail in SAFe through the additive function of story points across the backlog. This is 100% agile because “there is value in the items on the right.” Processes and tools are valuable.
Combining standards of communication and practice with an agile mindset where the system respects people and culture, individuals and interactions over processes and tools, the system works for the benefit of all stakeholders. Delivery becomes more predictable. People have more freedom to be creative and innovate. Businesses are more profitable, missions have more success within budgets.
An agile team using relative estimating techniques should regularly reflect on how to become more effective by tuning and adjusting its estimating methodology accordingly. If the team is using story points as a language standard for relative estimating in a network [or not], then they should regularly test, inspect, and adapt their team baselines and method [PDCA cycle and feedback loops].
Stop here or keep reading to understand the why
agile Context Matters
I still remember when I discovered the Agile Manifesto in 2001. I thought it was great, so I signed it. At the time, I was developing software full time for the Government. I was also leading teams and the manifesto gave clarity and focus to a problem that I was already aware of and experiencing. Estimating was hard, and so was being predictable in software production. By 2001, the teams I was working on were already using XP concepts and “RAD”, rapid application development, to successfully deliver value faster than any others were doing it with phase gates and waterfall. We strongly desired to escape the prison of the WBS and task mastering because we wanted to focus on outcomes. The hell created by project management in the complex and chaos domain of software development held us back. As a creative builder, I always struggled with the iron triangle and software development. I wish I knew then what I know now.
Startup Culture and the agile team
Each team should be creating and making value flow without interruptions in their independent system, operating within the boundaries of the business, the vision established by leaders… the system of systems. In startup culture, this happens out of necessity, the reality of, and the limitations of resources and people in the startup.
One way to describe the heart of agile it is entrepreneurism. Entrepreneurism is, “a person who habitually creates and innovates to build something of recognized value around perceived opportunities.” Do we desire agile teams to be a raw factory [Taylorism] that simply receives inputs and instructions and churns out widgets to spec or a team that habitually creates and innovates building valuable solutions for business opportunities?
Startup culture refers to the values, beliefs, practices, and attitudes that are common in entrepreneurial companies, particularly those that are newly established and seeking rapid growth. Startup culture is often characterized by a fast-paced, dynamic, and innovative environment that encourages risk-taking, experimentation, and creativity. Sounds like a great agile software team to work with!
How do we become more predictable at scale?
When we consider agile at scale this gets more complicated. Business wants predictability and the capability to reasonably forecast production. This is so the business can be managed to profitability, stability, or reliable mission success for Government entities. In the case of software development, the nature of the craft, the art, of coding and developing software products has inherent variability compounded by the system the teams operate in.
We learn how to make value flow without interruptions, together –with everyone in the value stream. The Agile Manifesto says, “We are uncovering better ways of developing software by doing it and helping others do it.” This means that the value stream and flow must be understood. We have to map it out. Measure it. And focus on the delays so that teams can remove waste and clear the way for recaptured capacity to be spent on architecture or new features. We have to organize around value and tap into people’s creativity and desire to innovate. To create space for autonomy, mastery, and give people purpose.
We teach teams working in or on large cyber physical systems at scale the foundations from the Agile Manifesto. We then add guidance for standardizing communication and language to provide an organization with channels to efficiently transport stories and desires about value. As described above, establishing a Capacity Allocation Guardrail that the system can use to produce meaningful roadmaps to predict, with some degree of accuracy in a given system, future delivery of value in flow.
In order to establish a guardrail for an entire portfolio, perhaps hundreds or thousands of people working on a solution(s), SAFe describes in guidance practices that organizations can use to create an operating model with structure that frees teams to be agile, but also work towards common goals and vision for the business. Agile teams use relative estimating with a common story point sequence of numbers. Features are estimated through progressive elaboration, story mapping. Epics are estimated through the creation of an MVP, the aggregation of the features, the roadmap, available capacity, and so on. The key is the PDCA cycles and the feedback loops.
What did the agile say?
The manifesto did not establish a set of rules and boundaries, a manuscript on how to judge whether something is acceptable to those agile values. The entire manifesto is only 300 words. In fact, it only proposes an ideal for values and principles that are fairly open to interpretation. Anything after that is the opinions of the 17 or the noise of the many. It does not prescribe anything. It doesn’t mention story points at all. Or Scrum, or XP, or SAFe, or lean, explicitly.
Stories [user] are an XP concept. Story points as a concept for estimation were created during the progression from XP, to ideal days, out of frustration with miscommunications. Jeffries describes how they needed to have a way to simplify communication for an estimate with acceptable risk balanced across the team and business (popularized and expanded by Cohn) so they stopped using ideal days and just started calling them story points. They used story points to estimate the amount of work for an iteration.
-Ron Jeffries
“And we really only used the points to decide how much work to take into an iteration anyway, so if we said it was about 20 points, no one really objected.”
There is a great quote from Jeffries that captures the essence of the coders thinking about the infamous question, “How long is it going to take?” He says, “We quickly went to what we called “Ideal Days”, which was informally described as how long it would take a pair to do it if the bastards would just leave you alone.”