Skip to main content

Harmonizing User Story Estimatimation across Scrum Teams !!

Last post 08:29 pm April 28, 2022 by Daniel Wilhite
4 replies
06:04 pm April 28, 2022

Hey great minds, 

My Agile Manager last week sent out a note to us the Scrum Masters stating that they want us to harmonize the way the teams do story points estimation. Before all teams were committing each developer to a maximium of 8 user story points per sprint, now they say each developer should be commiting to a max of 13 user story points in a sprint. Is this right?  The Manager also said the teams could have an average velocity of 100. however, since I joined the company and teams I have been revolving at, no team has ever had an average velocity above 78. Help me out! this is a debate ongoing at my company.

Thanks for your kind input.


07:28 pm April 28, 2022

I'll start with the obvious.  Have you ever seen anything mentioned the Scrum Guide about an Agile Manager? Or anything about having cross team harmonization on anything? And for that matter, can you find any reference to user stories or story points? 

This is a quote from the Scrum Guide's section that explains the Scrum Team.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

Since you have an Agile Manager dictating conditions on the Scrum Teams, what do you think that says about your organization's commitment to having Scrum succeed?

And before you say something like "how do you compare teams/developers to each other if no one works in the same way", I will answer.  You don't compare teams or developers to each other.  Each team is responsible for their own work, the value that they provide to the stakeholders, and holding each team member to be professional. 

As a Scrum Master you have responsibilities to your organization.  This is from the section of the Scrum Guide that explains the Scrum Master role.

The Scrum Master serves the organization in several ways, including:

  • Leading, training, and coaching the organization in its Scrum adoption;

  • Planning and advising Scrum implementations within the organization;

  • Helping employees and stakeholders understand and enact an empirical approach for complex work; and,

  • Removing barriers between stakeholders and Scrum Teams.

This sounds like an excellent opportunity for you and your fellow Scrum Masters to help the organization.  

Now, some questions you could ask your Agile Manager.  

  • What is the reason for this?  What benefit does it provide our Scrum Teams to consistently deliver value to our stakeholders?
  • Why do you want to create an impediment for our teams by instituting these policies?
  • What is wrong with the way we work now?  what evidence do you have that we failing to deliver valuable usable increments in each Sprint?

I'm not an advocate of using user stories or story points but I have used these quite successfully.

  • What does 13 story points mean? If each team has a different perspective on points, why would standardizing on this provide any benefit?
  • Have you considered that teams may start increasing their story point estimates to meet these rules and that no change in the delivery of value will be realized?

 


07:56 pm April 28, 2022

I would recommend that the people at your company read Ron Jeffries' article "Story Points Revisited". He worked with the XP team that developed the original ideas behind stories and story points and isn't really that thrilled with how story points are used today, to the point of being sorry for perhaps inventing them.

It seems like management is trying to force points back into ideal days. At that point in time, you might as well use real units and estimate in ideal hours or ideal days to begin with. That would at least make it possible to look at actual time and figure out how many clock hours equates to an ideal hour or what the team's load factor is.

However, since there's so much energy being spent on estimation, I'd even present the idea that spending so much time on estimating is wasteful. Estimates are only useful to the team at planning time. Perhaps using the flow metrics of cycle time and throughput would be just as useful and would allow the teams to plan based on actual historical performance rather than guesses and estimates made at or before planning.


08:28 pm April 28, 2022

Having individuals commit to story points doesn't sound very productive. Wouldn't it be better to have each team commit to a valuable Sprint Goal which the members have agreed, and which they achieve by self-management, rather than by having a so-called "agile manager" trying to tell them what to do?


08:29 pm April 28, 2022

I agree with @Thomas. If the Agile Manager is trying to do something so that forecasting/planning is easier, this would be a better option.  Read these books from Daniel S. Vacanti.

Those two books can help you with the flow metrics that @Thomas mentioned and how to understand their use.  But as I said before, they benefit each team individually and should not be used to compare across teams.

But if this is not about forecasting or planning, I stand by my first response. 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.