If you’re doing agile software development with Scrum, you’ll need a name for your team. But what should the team be called and how should you choose your Scrum team name? This article will answer those questions for you and provide some Scrum naming conventions. So you won’t be stuck for any agile team name ideas. Let’s get to it!
In Scrum, you have a small cross-functional team called a Scrum. So it made up of different people with different skills, working together. You don’t have a team of analysts handing specs to a team of software engineers who hand code over to a team of testers. That encourages phase gates, waterfall, sign-offs, and other practices we want to avoid. It goes against Lean principles.
The Scrum team is cross-functional. And should own the product’s value stream end to end. Which means they have all the skills required to do all the work to produce a working product increment. One that meets the team’s Definition of Done.
So the team can’t be the “integration testing team” or the “middle-tier agile development team”. It needs some other kind of name, that specifically refers to that team, not the work they do.
There are a few different approaches to a cross-functional team name. I’ll go through all of them and their pros and cons. You can choose some more technical / product names, some more serious names, or some funny Scrum team names. So you can choose one that feels right for you and your Scrum team.
This is a common one and is straightforward. You name the team after the product they are working on!
So if the team is building a product called Supermaster, the team is called Supermaster. If there is another team working on another product called Marketmeter, then they are called Marketmeter. Pretty simple!
The advantage of this is that it makes it very clear what the team is doing. Nobody needs to figure out what the Godzilla or Ninjas team are doing. The name explains it all right away.
There are a couple of disadvantages to this software team name approach though. The first is that it is not very fun or original. The team doesn’t get to mark or brand their team in any way. Their name is effectively chosen for them. The other disadvantage is that the team might eventually move onto working on another product.
Maybe that first product gets effectively finished and goes into BAU or Operations mode. Or maybe the product fails and gets shelved. And now the team moves onto a new product, maybe called Super-1000. Do they change their name again? That might get confusing or annoying. Or now there is a Marketmeter team who work on a Super-1000 product. Which might get people very baffled. Or you might end up with BAU or DevOps team names, which is a path not to go down.
For those reasons, I don’t like this approach.
You can also have teams use a simple generic name. For example, you might have Red Team, Blue Team and Green Team. Or teams 1, 2 and 3. Or teams North, South, East and West. You get the idea.
This is good because it is very simple and scales out pretty well. The names are also not tied to products so you don’t have to worry if the team works on something else.
The problem is that the team might feel the names are pretty boring and generic. Team 2 doesn’t really say anything about the team and nobody had any real input into it.
So I don’t love this approach to naming Scrum teams either.
You can also get the team to pick a name that they feel reflects themselves. It can be anything – a superhero, a movie, a monster, a concept, a story character, anything.
So you could have team Superman, team Godzilla, team Pirates, and so on.
It might sound silly but this is usually my preferred approach. The advantages of it is that the team is not tied to a product name so you don’t have a problem if they switch products. You also get the team to be creative and choose a name they feel reflects themselves.
A lot of people like to have input and build a kind of “character” or “theme” for their team. So this is a perfect opportunity for that. The only disadvantage is that people outside the team might find the name strange or confusing. It won’t be immediately clear what they are working on.
However, I feel the pros outweigh the cons here, and this is a popular option.
Another variation of this is if you have a lot of teams, have them all choose a name from a theme or set of names. For example, at one place I worked, the teams were all named after Game of Thrones houses. So there was a Team Stark, Team Lannister, and so on. Teams got to choose what their house was.
This worked well because the names were connected and easy to remember, but they were also fun and people got to choose a name that they liked.
So you might end up with a fun and nerdy engineering team names generator.
Who should make this choice though? And once the type of agile team name is chosen, how do you come up with actual name?
In the spirit of Scrum, this really should be a team choice. Ask the team! A lot of the time, the team will choose the “brand” team name option. Or they might want to be tied to the product they are working on. Ask them! If there is disagreement, let them vote, rather than just have a team lead overrule and tell them what to do.
And if they want to use a brand name, use a voting system to come up with the actual name. There are lots of free online voting tools that you can use for this. People want to feel they have a voice in these matters.
In summary, involve your team, come up with something clear and fun, and make sure people have a voice. They should feel proud to be part of their team and their team name. This can really help with Scrum team building / Agile team building, and other activities (such as Scrum sprint planning).
Do you have any different ideas about Scrum team names? Let me know in the comments! I will read and respond to every one.
Naming a team (i.e. agile naming practices) isn’t just fun, it can also help with clarity and reduce confusion. If you only have one Scrum team, then it is probably fine. But if you have two, three, or even four or more teams, it can get tiresome and confusing to continually explain which team you are referring to.
The article above provides some clear guidelines on how to help a Scrum team choose it’s name, based on its Scrum team dynamics, work type, and so on.
No they shouldn’t. A Scrum team should be cross-functional and should have the core Scrum roles or accountabilities (Scrum Master, Product Owner, and Developer). And follow the normal Scrum team structure.