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

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.

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

Sorry, I'm not following.

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.

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

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?  

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

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. 

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.

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).

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.