Skip to main content

How-To Determine Velocity for Multiple Teams Involved in a Sprint?

Last post 11:04 am February 16, 2024 by Anand Balakrishnan
10 replies
08:54 pm February 7, 2024

Hi. I'm trying to wrap my head around how to determine velocity for a sprint when multiple teams are involved. 

For example, we have work items that will always involve the Dev team and the QC team, and sometimes the Database team.

However, a dev might say a work item is a 5, but QC's estimate is 8, and maybe it's a 2 for the DB team (total 15 points).

How would I go about determining team velocity for a 2-week sprint, for example, when I have many different teams involved who will have different estimations for work items?

I'm sure I'm overthinking this, but any help you can give would be greatly appreciated.


09:29 pm February 7, 2024

You don't have a team. That's the problem. You've got different workgroups, and there is no clear accountability for work being Done.

Velocity is the rate at which work is Done. Until the matter of the Developers' accountability for this is resolved, velocity will be unmeasurable.


10:47 pm February 7, 2024

"Until the matter of the Developers' accountability for this is resolved, velocity will be unmeasurable."

Sorry, I'm not following.


11:38 pm February 7, 2024

For example, we have work items that will always involve the Dev team and the QC team, and sometimes the Database team.

Scrum Teams are fully cross-functional, which means one Scrum Team has all the skills needed to turn ideas into valuable, useful, and 'done' Increments by the end of each Sprint. Not 'almost' done or '99 percent' done. 100% done and potentially releasable.

Velocity measure Done work each Sprint, as mentioned by Ian. The Dev, QA, and Database work by themselves doesn't provide customer value or anything useful until all the components are connected and tested. The velocity of each team is actually ZERO because of the way they are organized.

When using Scrum we are challenged to think differently and challenge the way it's always been done. Being a change agent isn't easy, yet accepting the status quo isn't acceptable if we can bring change. A Scrum Master is accountable for helping the teams become cross-functional and self-managing.


05:29 am February 8, 2024

How-To Determine Velocity for Multiple Teams Involved in a Sprint?

The question is not fully clear. Do you have multiple teams or a single team with people in dev, QC and DB ? I assume it is the former and your struggle is to align the work delivered by these teams.

I agree with Ian and Chris here. You seem to have a component-based team at the moment where each team i.e. dev, QC, DB seems to work in silos. You need to think about moving to a feature based structure and your team should have people from dev, QC and DB as it is their combined work that will give an increment of value (which probably is the point Ian seems to suggest when he says you do not have a team and a shared accountability also developers are dev,QC,DB and anyone else who contributes to build a done increment). 

Measuring velocity will be possible only once the team is in place and producing valuable increments in each sprint. The velocity is measured for the team rather than individual functions like dev, QA, DB. It is all about what you achieve together. Velocity is nothing but the number of done story points each sprint and when you do multiple sprints you can get an average velocity which will help you forecast how much work to actually take in a sprint


05:22 pm February 8, 2024

Agree with everything already said.  But let me try to add my spin in case it helps you better understand.

A Scrum Team is a group of individuals that have all of the skills needed to take a great idea and turn it into something that can be delivered to the stakeholder that asked for the great idea.  Software, hardware, medical treatment plans, large event that allows vendors to showcase their products are all examples of "products" that I have been involved with using Scrum. 

Velocity is the rate at which work is done.  Some people try to use story points to measure this (a practice I personally think is useless because it is based upon guesses), others use throughput or cycle time, while there are others that come up with their own scales.  Velocity for a Sprint is the rate at which a Sprint Backlog Item goes from "hey we need to work on this" to "there is nothing left for us to do on this Sprint Backlog Item. It is now part of the increment."  You can not measure velocity across multiple teams as each team is evaluating the work on their own basis and standards.  You need consistency to do the measurements. If each team works in a single domain, they measure based upon that domain. 

What everyone is trying to explain is that instead of having a developer team, qc team, db team you need to have a single team that has individuals that can be accountable for doing the development, qc, and db work that will estimate the effort for the entire team as a single unit rather than estimating each specific domain independently. Organize teams to have all the skills needed to do the work to turn Product Backlog Items into "done" increments of value that can be delivered to the stakeholders in each and every Sprint.  There shouldn't be a handoff of work from one team to another in a Sprint. 

Does this help?  


06:13 pm February 15, 2024

Sorry for the delayed response. For some reason, I was not getting emails that people were responding (other than Ian's).

I appreciate everyone's comments and insights! Very informative and helpful.

Do you have multiple teams or a single team with people in dev, QC and DB ?

My apologies. It's multiple teams.

You seem to have a component-based team at the moment where each team i.e. dev, QC, DB seems to work in silos. You need to think about moving to a feature based structure and your team should have people from dev, QC and DB as it is their combined work that will give an increment of value

This the kind of info that I was looking for. I appreciate this.

also developers are dev,QC,DB and anyone else who contributes to build a done increment

Devs are not QC and DB in my org. There are 3 completely separate teams. 

Daniel, yes, I believe that helps. The challenge now is how the heck do I make that happen! haha


06:39 pm February 15, 2024

In reality, having 3 different organizations of people with separate management chains is not an issue for Scrum. The key is being able to have a dedicated group of people from those 3 organizations work together as a single team, managing their own work, making decisions that are right for the work at hand.  If you can achieve that, it will allow them to work as a single team of people with all of the skills needed to accomplish the work.  Then instead of them trying to estimate for each discipline, they can communicate, collaborate and come up with an estimate of doing all of the work as a team that will be needed to turn that great idea into an increment.

I know that is strange to some companies.  I mean who in their right mind would actually communicate and collaborate on common work?  But if you can get management to support a 6-month experiment, it just might open some eyes and minds across the company. It has worked for me a time or two. 


09:09 pm February 15, 2024

If you can achieve that, it will allow them to work as a single team of people with all of the skills needed to accomplish the work.  Then instead of them trying to estimate for each discipline, they can communicate, collaborate and come up with an estimate of doing all of the work as a team that will be needed to turn that great idea into an increment.

This is what I needed to hear. Thank you, Daniel!! Makes total sense.


09:11 pm February 15, 2024

But if you can get management to support a 6-month experiment, it just might open some eyes and minds across the company.

I am management haha. I'm new here, have had time to see how we currently do things, and am trying to make us more efficient. My goal is to teach our product owners and everyone else involve about DA and how we can make changes for the better. I've just never been in an environment quite like this, so it's new to me (at my previous job, the devs did it all: Dev, QC, and DB).


11:04 am February 16, 2024

Devs are not QC and DB in my org. There are 3 completely separate teams. 

Probably I confused you here, the point I was trying to make was once you transition to a Scrum team (cross functional) there is only one role in Scrum for the people responsible for delivering a done increment and that role is Developers (it can include QA, DB, Coders etc.)

Daniel, yes, I believe that helps. The challenge now is how the heck do I make that happen! haha

If you go buy the Scrum guide you should probably assemble the concerned people in the room, inform what is needed and let teams self organize :)

A good starting point is to check the work you do and see what the skills are that you need to accomplish the work. If you need developers, QA and DB then you should have a team with a mix of these people. I am not aware of your organization structure here like do these developers, QA, DB people work on different tasks for different teams? If the answer is yes then as Daniel mentioned above you will have to have a discussion with the management and see if we can work with a feature-based structure. If I consider QA as a department they probably work with multiple teams and is it possible to have x number of QA's for your team exclusively. Now the QA guys will have 2 places where they report one is the project they are tagged to and the second is the QA department. Once the work on your project is done the QA guys are relieved from the project and they go back to their parent i.e. the QA department where they can be allocated to other projects or do some department related work. 


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.