Skip to main content

Is the Scrum Master the right person to answer this question?

Last post 05:08 pm December 18, 2019 by Timothy Baffa
8 replies
04:44 pm December 15, 2019

The following scenario is given:

Team A finished 50 story points in their last two-week iteration. Team B is working on a similar project to Team A, but Team B has twice as many developers as Team A. Team B also completed 50 story points in their last two-week iteration. Senior management have noted this and have requested an explanation from the Scrum Master for Team B. If you were Scrum Master for Team B, what explanation might you give to senior management?

What would be your answer?

I know velocity can't be compared for 2 teams, however what would be the best answer that the Scrum Master could give?

Thank you 😊 

06:09 pm December 15, 2019

Without knowing all the facts, this is highly subjective. 

Team A - Possibly has more experienced, highly productive members on their Development Team. 

Team B - Possibly has many junior Development Team members, which means that senior members are having to split time between doing work and training. Also possible that some members had time-off. Also possible that some members of the team are not as productive, goal-driven or motivated as Team A. 

When I've given such "assessments" as a management consultant, I have explained that anything I state, is based on my observations and that it is not necessarily the whole truth. Management will sometimes use these assessments to make decisions on personnel.

At the end of the day, you have to remind management that they're dealing with people. Some people will be better, more productive, more efficient, more skilled and better with time management than others.

09:08 pm December 15, 2019

Team's should not be compared or measured using velocity. Each team can have different scale of story points and team doing 100 story points may deliver less than second team delivering only 20. Velocity should be used only by the scrum team - mostly to know their pace, know how much they could take on planning. And the senior management should receive this explanation I believe.

What should matter is how much the team delivers business value. By business value I mean how many useful features have been added by them in the sprint. Management should observe how much is produced by teams. If they need numbers, you can try to do some brainstorming how to measure that in your context.

Also - one sprint should not be deciding. We should observe teams in couple of sprints.

I would invite "senior management" to the sprint reviews. In this way they can see how the money of the company is spent, they can see what actually team did in past sprint. And they can provide feedback. If they have doubts team is implementing useful features, they should discuss this with the PO why they put these features and not the others at the top of the backlog. If they doubt about the team's speed in implementing features, they should discuss directly with the development team or with their supervisor (depending on the hierarchy in particular company). They should be able to explaing the situation precisely.

12:07 am December 16, 2019

In addition to what has been mentioned about comparing teams and educating management on relative estimation, no one metric is helpful or will tell you everything. Here's why.

What if one of the Development teams were cutting corners, building up lots of technical debt and has poor quality? Or maybe not, but they are working overtime at an unsustainable pace, the developers are unhappy and about to leave the company? How helpful is velocity now?

There's also Goodhart's Law: When a measure becomes a target, it ceases to become a good measure. Sometimes people know they are being measured, and the metrics start to become 'gamed'. Let's bump that 5 pointer to an 8, we have to keep up with Team X.

Measure outcomes (related to value) rather than outputs (velocity, points). And the conversations are always more important.

Here's an article I wrote on the topic, share this with your leaders:

Scrum on!


08:07 am December 16, 2019

what would be the best answer that the Scrum Master could give?

"What problem are you trying to solve?"

08:36 am December 16, 2019

"What problem are you trying to solve?"

This and what Chris already mentioned:

 When a measure becomes a target, it ceases to become a good measure.

Satisfying metrics targets is not a goal, but having management treat it like this will distract the team for delivering value and have them focus on clearing targets. 

03:51 pm December 16, 2019

"Senior management" is presenting Scrum Master B with the perfect opportunity to coach them on how Scrum focuses on the value delivered and not the amount of work being done. I'd answer with a question.

Is Team B delivering value to the customer in a manner that satisfies their needs?

That is where "senior management" should be focusing their attention, not on the team's mechanisms used to relate various items of work to other items that they do.  The goal of a Scrum Team isn't to complete story points. It is to deliver incremental value at the end of each sprint. 

As mentioned previously, if "senior management" starts comparing teams ability to complete estimated work the teams will start to scale their estimates to make it appear they are doing more.  It will not be long before the 5 point stories start to become 13 points and you will start to see more 20 point stories appearing in sprints.

All responses in this thread have good advice and a pretty common message. Good luck with your coaching moment. 

07:17 pm December 16, 2019

Prime position for the Scrum Masters, for sure! Obtaining data is easy...but knowing what to measure with that data is not.

There's nothing 'wrong' with measuring some stuff about the team, because it helps validate improvement. What makes velocity measurements wrong is because it's not the intent of that tool. We also don't want to compare output between teams. That's not to assume measuring stuff between teams independently is automatically wrong.

That said, I have two criteria:

  1. Have a single, concise use case
  2. The use case connects to the purpose of Scrum

Managers need to manage, so get their perspective. Ask them what they feel they need to report on. Correlate that back to Scrum and make attempt to make a connection. 


05:08 pm December 18, 2019

In addition to all of the excellent advice already presented in this thread (and apologies if I am repeating any previous responses), my 'answer' ideas are as follows:

  • Ask your Senior Management why they are interested in analyzing such a small sample size?
  • Ask them why they believe story points are 'normalized' across teams?
  • Ask them to read the following article first, and then get back to you:

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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.