Understanding Scrum development teams: who are they and what do they do?

The EasyRetro blog often focuses on tips to help Scrum Masters get the best out of their team, but we rarely talk about the team themselves. To set that right, this blog post will look at the Scrum development team in detail — who they are, what they do, and why it’s so important to choose the right people for the job.

What is a Scrum development team?

Strictly speaking, everyone who’s involved in a Scrum project is part of the development team. For the sake of clarity, though, we’re going to talk about the people who actually build the product.

The term “development team” implies that this group comprises engineers only, but in actuality, the team can include writers, designers, programmers, Agile experts, and so on.

What are the Scrum development team’s responsibilities?

This is another big question to answer.

Each team member’s responsibilities will depend on the job they’re undertaking. For example, a UI designer will spend the majority of their time focusing on accessibility and product flow. Meanwhile, the programmers will be focused on how to make the UI designer’s ideas work as intended.

That being said, there are a certain number of shared responsibilities for a Scrum development team, regardless of their specialty. After all, Agile methodologies can’t function if the team is working towards separate goals.

Perform sprint execution

This may seem obvious, but the key task for a development team is to actually undertake sprints and ensure deadlines are met.

The team needs to self-organize in order to plan, carry out, and manage a sprint. During sprint execution, the development team members perform their specialized tasks to produce an increment. These tasks can include designing, programming, integrating, and testing backlog items to achieve the goals set during sprint planning.

Inspect and adapt on a day-to-day basis

Agile and Scrum methodologies require regular updates and transparency between team members. This is why we have the daily standup.

These standups are quick, 15-minute meetings that focus on reviewing what tasks have been achieved and what is left to be done. Its bite-size and straight-to-the-point format gives the team an insight into how the sprint is going and can pinpoint any issues that require addressing before moving forward.

Most standups won’t affect the day-to-day flow of a sprint, but they could drastically alter workflow in some situations. That’s why it’s vital that everyone attends each day to avoid being out of the loop.

For an in-depth look at the Daily Standup, take a look at our Ultimate Guide to the Daily Standup Meeting.

Groom the product backlog

A product backlog is a prioritized list of work for the development team. These tasks will be taken from the product roadmap and its requirements, with the most important items shown at the top of the product backlog, so the team knows what to deliver first.

In each sprint, the development team must dedicate an appropriate amount of time preparing for the next sprint. The majority of this planning will revolve around “grooming” the product backlog. This involves creating and refining, estimating, and prioritizing product backlog items.

In every sprint, the development team should dedicate around 10% of its overall workload to assist the product owner with all these activities.

Plan the sprint

Sprint planning is vital for a successful sprint. As with all Agile practices, it’s a fully inclusive process that involves the full team, a facilitator (Scrum Master), and a product owner working together to establish goals for the next sprint. Once the goal is defined, the team determines a high-priority subset of the product backlog items which they should build to achieve that goal.

The amount of time that needs to be allocated to sprint planning is relative to the length of the sprint. For example, a two-week sprint would require half a day of planning, four-week sprints require a full day, and so on.

Inspect and adapt the product and process

As each sprint comes to an end, the development team takes part in two more inspect-and adapt activities: sprint review and sprint retrospective. Similar to the daily standup, the aim of these activities is to find out how much progress has been made, what went well, and what needs to improve.

A sprint review is normally an informal meeting involving the product owner, product manager, Scrum Master, development team, management, and stakeholders. The development team presents the product increment and receives feedback from the rest of the group.

Alongside the presentation, the group discusses tasks that have been completed, tasks that are still to do, any issues that occurred during the sprint, and the next steps. The sprint review is designed to offer insight into the product so far.

The sprint retrospective traditionally takes place immediately after the sprint review, though we recommend running both at the same time to save time, money, and resources. The aim of a sprint retrospective is to improve the development process by identifying ways to improve productivity and efficiency.

The development team will talk about how progress happened, rather than what progress happened. The retrospective is designed to offer improvements in workflow to get the best value out of your team.

If you’re still a little confused about the difference between sprint review and sprint retrospective, we have a great guide on our blog that offers an in-depth breakdown of their key differences.

What’s the ideal size for a Scrum developer team (is there even such a thing?)

According to The Scrum Guide, a developer team working with Scrum should be between three and nine people, depending on the size of the project. This does not include the Scrum Master or product owner.

However, teams outside of those parameters can still work with Scrum methodologies. Ideally, a development team should be small enough to remain agile, but large enough to complete the amount of work required for each sprint. Achieving the right balance will help your team work in an Agile fashion and bring the most value to each project.

Too many team members…?

In most product development cycles, it’s all hands on deck. The deadline is approaching and the higher-ups are tasking the entire office with finishing the product. That kind of chaos doesn’t fit with Agile workflows, nor should it be the usual practice to operate this way. For an Agile team, you want no more than nine members — anything more than that will result in convoluted communication and disorganization between team members.

You may be thinking “less is more” seems to be key to a successful Agile development team, but a team that is too small presents its own issues.

… Or too few?

Smaller development teams with fewer than three members may seem like a great idea to ensure workflow stays Agile, and yet a team that’s too small can face more problems than positives.

There will be fewer interactions, which quickly translates into low productivity. The lack of hands on deck will also extend sprint lengths due to fewer tasks being completed simultaneously — and that’s before we factor in possible skill constraints for more complicated challenges.

What Scrum mindsets and practices should development teams follow?

Scrum is, by nature, a fast-moving and flexible methodology to work with. To get the most value out of Scrum, you need to be open-minded and ready for anything that might crop up. It’s one thing to be a great programmer or designer, but to be a successful member of a Scrum development team, you need to have the correct mindset.

Let’s take a brief look at what that might entail…

Self-organizing

This is the key mindset for any Scrum development team member. There are a lot of tasks and responsibilities they have to manage, so understanding how to prioritize those is essential, especially without a top-down figure to keep them on track.

Musketeer attitude

We all know the famous catchphrase “all for one and one for all” — let’s think of this as a motto for Agile working. Going into a project with this kind of attitude can reinforce the collective ownership of the project.

You will succeed as a team, or you will fail as a team.

Commitment and focus

Commitment to the project comes hand in hand with taking ownership. There is only a limited time available during sprints, so every team member needs to be focused on the sprint goal rather than attempting to multitask.

Transparent communication

Every team member needs to be completely upfront with others. If there is a problem, they shouldn’t be afraid to speak up and ask for help as that only serves to delay the sprint’s progress. You don’t want to get to the sprint review and find a hole in the product that could have been fixed during the sprint.

Looking for tools to help collaboration and communication? Then look no further than EasyRetro. And for further tips and tricks about Agile working and Scrum mentality, then visit our blog.