Do we need to normalize on estimation across teams in our organization to make Jira Align work?

[#1]

In many of the Jira Align advisory service engagements, we get a question similar to the one mentioned in the headline of this article. The short answer has two parts and is:

"It depends, from a technical solution point of view. You should, from a ways of working point of view."

Before I dive deeper into the 2 parts of the answer, I would like to explore what I am talking about when I talk about normalizing estimation.

1. Estimation technique

   Effort can be estimated with different practices and normalizing estimation entails the consolidation of those - ideally into one practice used across the entire organization.
   
   

2. Estimation pattern

   Within the usage of one estimation practice, different teams can have different estimation patterns. For example, Team A could estimate story X with 5 points while Team B estimates story X with 21 points. When talking about normalizing estimation patterns, the estimation patterns of teams should converge towards one estimation pattern across the entire organization.
   
   

3. Don’ts

   Velocity is not an indicator of team performance across teams.
   Even if an organization achieves a high degree of estimation normalization, there will always be nuances in individual team estimation patterns which will make this statement to be true.
   
   
   

It depends, from a solution point of view.

Jira Align asks for some prerequisites concerning team level estimation to make financial calculations and capacity planning work which boil down to “Stories need to have story points.” Dive deeper into the details in the Jira Align knowledge base.

All Scrum teams estimating with (story) points do not need to normalize on estimation - from a technical point of view. Jira Align can handle different point estimation patterns. The team spend per point is normalized and averaged on the program level. The following graphic shows this nicely - for an example with different spend per point on the individual team levels which could be caused by different estimation patterns. This applies to all other estimation scenarios described below.

Picture: How is the program spend per point calculated? - From the Jira Align knowledge base

For all Scrum teams estimating with T-shirt sizes or similar other estimation concepts, the t-shirt sizes need to be converted into story points in Jira so that the story points can be synchronized with Jira Align. Technically, this solution could be realized manually or for example with a scripted workflow transition post function (a capability which is added to Jira by Apps in the Atlassian Marketplace, Atlassian solutions partners could help with the implementation). From my perspective, this solution and other solutions which come to mind would become very hard to support if the conversation would be different for individual teams, so this aspect might create the need for some normalized estimation across teams.

All Scrum teams which do not estimate (deliberately) and all Kanban teams - which do not estimate by nature, need to normalize the story size of the stories they work on and a standard story point value needs to be populated. This means that those teams do not necessarily have to normalize estimation across teams as well. 

• For Kanban-teams, auto-population can be configured in Jira Align for each individual team (link to Jira Align knowledge base).
• For Scrum-teams, the population can be done manually or via an automation in Jira, for example via a workflow transition post function.
  
  
  

You should, from a ways of working point of view.

No matter if you decide on story point estimation or t-shirt-sizing of stories with roughly aligning on what individual estimation values mean or normalization of stories with no further estimation, this effort will entail benefits for the respective organization. 

• Conversations about estimation will help to increase predictability across the entire organization.
• Communication about estimation will become clearer and more frictionless, both within the Agile @ Scale initiative and with stakeholders outside that initiative.

Note that stable teams - by many thought leader in the agile community called "the foundation of agility @ scale" - support normalizing estimation efforts substantially. Normalizing estimation on a team level successfully requires a team to train the estimation muscle together over several iterations. If a team is constantly busy with integrating new members and adjourning leaving members it is very hard to work on this capability sustainably.

Got any thoughts on normalization of estimation? Let's discuss!

[Mark Cruth]

Fantastic article @Philipp Barry and great insight into how normalization plays into the usage of Jira Align (especially from a financials perspective). Another good community article to check out is on the Estimation Conversion functionality and how it impacts the rollup of things like story points in Jira Align. Applying some level of normalization to how an organization sizes work aids in how we estimate higher level work items (e.g. Features, Epics) and forecast that work out. My thought here is that our goal is not to say "1 story point = <insert measure of time>" but for everyone to be in the same ballpark. 

[Anton _Tech-5_]

Great article. Although we don't use Jira Align, the estimation normalization question arise frequently and has not been solved yet. 

BTW, since you touched estimation methods and T-Shirt sizes translated to Story Points, our Magic Estimations app comes with T-Shirt sizes support out of the box and saves estimates in SP.

[Philipp Barry]

Thank you for sharing that article, @Mark Cruth!

@Anton _Tech-5_ Thank you for your perspective. Just FYI: I think users might not be able to access the link you shared.