The Scrum prescribes three roles - The Product Owner, The Development Team, and the Scrum Master. In this article, we will discuss The Scrum Development Teamand understand how this role helps in the success of Scrum. We will go through below topics -

• Who is the Scrum Development Team?
  • What are the Responsibilities of the Development Team?
  • What are the Characteristics of the Development Team?
  • What's the ideal size of the Development Team?
• Common Questions on Development Team

Who is the SCRUM Development Team?

It is a self-organizing, cross-functional team of people who are at the core of the Scrum development team structure. It is the team that is responsible for building the actual product increment and meeting the sprint goal. The success of Scrum largely depends on how successful the development team is.

What are the Responsibilities of the Development Team?

The development team performs several responsibilities during the Sprint. We will discuss these in detail, and see how these responsibilities lead to a successful sprint.

• Perform Sprint Execution - This is what the development team would spend their majority of time on. Once the Sprint planning meeting finishes, the team gets a Sprint backlog and a Sprint goal that they need to work. The development team self organizes themselves, and collectively decide how they will plan and manage this work. It includes designing, building, integrating, and testing the sprint backlog items to create a potentially shippable product.
• Inspect and Adapt Each Day to Meet Sprint Goals - One of the critical strengths of the Scrum model is its agility and ability to adapt daily. The Scrum team participates in the daily scrum meeting, where they collectively inspect the progress towards meeting the sprint goal. Based on the growth, they adapt the plan for the day. It allows them to ensure there are no surprises towards the end of the Sprint.
• Groom the Product Backlog - While a significant focus of the development team is to complete the sprint backlog, they still need to spend some time on backlog grooming. The product owner is primarily responsible for backlog management. However, the development team assists him in refining, estimating, and prioritizing the backlog items. Usually, the development team spends a maximum of 10% of its available capacity for this activity.
• Plan the Sprint - At the start of each Sprint, the development team participates in the Sprint Planning meeting, along with the product owner and Scrum Master. The Development team helps the product owner in defining the goal of the Sprint. They also determine how much work they can do realistically to meet the Sprint goal. It is usually done by allocating story points to each story and comparing it with how much story point the development team has historically achieved in a Sprint. If the development team has any questions on the requirement, they will clarify that with the product owner.
• Inspect and Adapt Product and Process - At the end of each Sprint, the development team has two opportunities to Inspect and Adapt - Sprint Review and Sprint Retrospective.

In the Sprint Review, the development team demonstrates what they have accomplished in the Sprint. The participants include Scrum Master, Product Owner, Sponsors, and any other stakeholders. It allows everyone to inspect the increment and decide how to move forward.

In the Sprint Retrospective, the development team, along with Product Owner and Scrum Master review how well the Sprint executed, and what are the opportunities for improvement. It could be process improvement or technical improvements.

What are the Characteristics of the Development Team?

We have got a good hold of the responsibilities of the development team. Let's discuss the characteristics that the development team needs to exhibit so they can fulfill these responsibilities.

• Self Organizing - One of the critical characteristics of the development team is that they self organize. What this means is no one tells them how to achieve the sprint goal. They organize themselves and figure this out. The Scrum Master or any other stakeholder doesn't provide this leadership guidance. Nobody tells the development team how much they need to do in a sprint. They decide on their own in the sprint planning meeting. Off-course, the Scrum Master is there to ensure that they follow the right process (Story points, capacity consideration, etc.)
• Cross-Functional - Development teams in Scrum need to be Cross-functional. Together, they should possess all the skills necessary to complete the sprint goal. They shouldn't need help from people outside the Scrum team to finish their sprint work. It allows development teams to have better control over their work, without depending on others (which is primarily the essence of the Scrum framework).
• Without Title - Have you heard about the Leader who had no title? The same applies to the Scrum team. Every member of the team (except Scrum Master and Product Owner) is a development team member. There are no further titles given irrespective of the work they do within Sprint.
• No Sub Teams - Scrum doesn't create any sub-teams within the development team. There is no concept of a testing team, dev team, UI team, or architecture team. The teams will still do that work, but there will be no bifurcation on that basis. It is why the development team is always multi-skilled.
• T Shaped Skills - An ideal development team has always got T Shaped Skills. It means that there is always one skill (like Java, UI development, testing, etc.) where they have acquired in-depth knowledge (Experts). Apart from that, there will be few other skills where they have got broad knowledge (they can contribute, but they are not experts). It helps the development team to be self-reliant and also not create any bottlenecks within the team.

• Team Accountability - All the members of the development team have a musketeer attitude -  All for one and one for all. They collectively own the responsibility of meeting the sprint goal, and they win or fail as a team. Having members with T-shaped skills further helps to reinforce this accountability as the development team is not dependent on only one person to do a particular task.
• High Bandwidth and Transparent Communication - Development team members need to communicate amongst themselves and also with Scrum Master and Product Owner. Usually, a Scrum team location is central, so team members should find the quickest and most efficient ways of communication (High Bandwidth). It merely means that if you can walk to another team member and close out a conversation in 5 min, don't waste time writing emails and having back and forth on it.

Apart from efficiency, communication should also be transparent. It means telling the status correctly in the daily scrum meeting, so there is no ambiguity in status. Additionally, one should highlight any issues and suggestions without hiding any information.

• Focused and Committed - You cannot achieve the sprint goal unless every member of the team is focused and committed to getting it done. During sprint planning, when the sprint goal and backlog finalize, each team member commits to it, and the team takes collective responsibility for accomplishing the goal.
• Sustainable Pace - One of the critical principles of Scrum is that the team works at a Sustainable pace. It means that they take the work that they can accomplish in a sprint, rather than being given an unrealistic goal by managers, and the entire team slogging to meet the targets. It helps in creating high-quality products and also keeps the team environment fun and stress-free.

What's the ideal size of the Development Team?

Scrum prescribes that the ideal team size is between 3 - 9 team members (3 and 9 inclusive). It doesn't include the Scrum Master and Product owners unless they are also executing the work of the sprint backlog (which is pretty rare)

So what's the logic for this range? It's quite simple! A team size of less than three will not be cross-functional. They might not have all the skillset required to get the sprint work done.

A team size of more than 9 creates communication challenges. It leads to inefficiencies in day to day coordination. Usually, Scrum teams prefer to have an optimal team size of 5-7 team members.

Common Questions

Who does the development team report?

We know that the Scrum Master is a servant leader, so definitely, the development team doesn't report to him in the organization. Usually, there are development managers within the organization, to which these team members will report. The development manager is responsible for hiring, up-skilling, and promotions of the development team member. He, however, has no role in day to day running of the Scrum team.

What can Scrum Master do if a team member is not performing well?

Again, the Scrum Master has no authority, but is he supposed to be a mute spectator? Not really!! The Scrum Guide doesn't explicitly state this, but let's try to infer it.

The role of the Scrum Master is to remove impediments that can prevent the team from meeting the sprint goals. So can we consider people or a team member as an impediment?

Various organizations deal with it differently. In some cases, the Scrum Master can escalate this to the development manager for a replacement. In other cases, the Scrum Master can talk to HR of the organization to remove the person. While all these options are there, these should never be the first option. The Scrum Master needs to enable the person, talk to him, give enough opportunities for improvement, and then take this step as a last resort.

Can we add an add/reduce team strength during Sprint?

It's a very tricky question, and the Scrum guide doesn't say anything about it. The only thing the Scrum guide says is that we cannot make any changes that would put the sprint goal at risk. It implies that you are allowed to make some changes to scope/resources as long as it doesn't impact what you signed up for in the Sprint.

It could happen that a team member doesn't have much work in a sprint despite having various skill sets. However, if you need him for the future Sprint (or you can train him on other skills), then there is no point in rolling him off.

Similarly, if the team thinks that they need additional folks in the future Sprint, you can always increase the team size, as long as it doesn't exceed nine folks. However, we should avoid doing it within the Sprint, as it may lead to communication/coordination challenges. The best practice is to negotiate the scope with the product owner if the team is falling short of completing the sprint backlog. Also, we shouldn't do addition and roll off frequently, and this often gets counterproductive.