According to Scrum guidelines, the size of a team should be between 3 and 9 people without counting the Product Owner and Scrum Master (unless they also undertake development tasks).

 A team of even 9 people can be a challenge to organize, especially when you want to ensure they all work using the same dynamic.

Through the experiences gained working in a large Scrum team, we will share some tips and steps that we follow in the hopes that they might help you organize your Scrum team more effectively.

Take it as an advantage

Having more people working together means having more different ideas, knowledge, and skills. Try to make the most of this. Each task and activity is more likely to be solved in a more creative and quality way when there are more people to provide their varying perspectives.     

A diverse backlog will reduce dependencies

Having more people in the development team will result in a wide scope of tasks and features that need to be implemented. 

  • For Product Owners – it is very important to have a sprint backlog that is diverse enough and prepared in advance in such a way that it will allow for minimum dependencies in the team. The definition of Done and Acceptance Criteria need to be clearly defined in each task.
  • For Scrum Masters – roughly define dates when certain activities need to end and make them transparent for the team. Even just having approximate deadlines will help organize and focus priorities.

It is crucial to set clear expectations for each team member, assign responsibilities and make a clear plan for each activity, but also to define and set deadlines for different events such as code freeze or e.g. end of the testing phase.

Enable self-organization and sub-teams

When there is a need for that, let people in your team organize themselves into ‘’sub-teams/horizontal teams’’ according to the tasks and topics they are sharing. People will be interdependent and there will be spillover in tasks, so it is important to keep track of interdependency between some people in the team or ‘’sub-teams’’ for your better organization and overview of progress or potential impediments. 

What you can do as Product Owner or Scrum Master to support ‘’sub-teams/horizontal teams’’ and ensure that they work properly includes:

  • You can create different communication channels for different epics you are working on and bring together the people working on it (e.g. you can use Slack for this). Channels focused on specific epics will help better collaboration in delivering features from those epics (you don’t have to scroll over your team channel conversations to find the latest information about progress on a feature you are interested in). 
  • Organize meetings or conference calls to discuss the current status of a certain epic and next steps occasionally, so that everyone involved stays updated.
  • Encourage team members to organize horizontal teams (DEV, QA, DevOps, UI/UX) and have their own (technical) planning sessions, sync meetings, and overall to have a level of independence when it comes to organizing their work. 
    • Technical plannings for horizontal teams have proven to be beneficial in our case since engineers need to think about the detailed implementation of a certain feature they are assigned to and present it to other team members, where they discuss the best approach to the solution together. This prevents situations where someone spends several days or even half of a sprint on a certain activity, which would need to change significantly after the peer review. They are usually organized the day after sprint planning and last around 1-2 hours.
    • Horizontal teams can have their own communication channels and backlog in the form of a Kanban board, where e.g. all QA or DevOps tasks are accumulated. They will have a better overview of the topics relevant to them, but also to trigger creativity and increase focus in finding solutions together.

Transparency is the key to good dynamics

Make all decisions, findings, doubts, and news completely transparent. All team members should be aware of everything that is happening in the team and on the project. You want to avoid misunderstandings, wrong solutions, or throw-away work caused by a lack of transparency, which you could have prevented. 

Scrum Master/Product Owner are persons that should take care of this. You can do it by:

  • Pinning and highlighting important notes on your communication channels;
  • Adding more people in email threads, especially if they are somehow engaged in the topic;
  • Create communication channels for certain topics the team finds relevant – Retrospective meetings are a great input for this! (E.g. automated notifications for system alerts, CI/CD, support channels, etc.);
  • Share minutes from meetings, highlighting the action items and its owners;
  • Avoid making decisions on your own, always have a second opinion and make it clear with your team (e.g. when planning next steps, defining deadlines, defining the scope of the sprint, etc.);
  • Syncing the whole team and keeping everyone up to date about the activities/events that affect the entire team, e.g. changes in deployment procedures, configurations, etc.

Document everything

It will be of significant help if you pay attention to documentation on time. Sometimes, due to the large scope of the tasks and a lot of things happening day to day, some things might get forgotten.

Document everything, from unofficial to official emails, discussions, since all of those contain something important and if you don’t keep it somewhere, information will get lost and might cause misunderstandings or problems later. Some examples of why documentation is important:

  • It is faster and more efficient to onboard a new team member when everything about the system can be found in one place;
  • Most of the time when some little detail is not written somewhere, that detail could be the resolution to some major issue;
  • You will save time when you get into a situation where you need to explain how a certain part of the system works;
  • When troubleshooting a certain problem that appears, it may help to speed up the process.

Having it all written, you will save time for your team and make a lot of future activities faster and easier. The best practice would be to try to include documentation as part of your Definition of Done. And last, but not the least, it is crucial to update the documentation regularly. 

Of course, we are not talking about making some official documents, but rather just saving important information you might need on the go (pinned post on the communication channel, page on confluence, comment in JIRA ticket, etc.).

Internal procedures can make it easier

Your team is agile, and you are working by Scrum, but there are many benefits of having internal procedures for your team. If you organize your team well internally, everything that you produce will be of a greater quality.  

You can, for example:

  • Define onboarding procedure for new team members (for needed accesses, onboarding workshops, intro into the system, etc.);
  • Have a defined procedure to support your team, e.g. removing impediments – it is important to know the responsible/contact person who supports those kinds of issues and what info needs to be provided, so you save yourself from ‘’circulating emails’’.

Listen to Murphy

When trying to make certain commitments, estimates, or just plan a certain release, always remember Murphy’s Law: “Anything that can go wrong will go wrong”. This actually doesn’t have to be related to the size of the team, but let’s say that possibility is increasing when you are working with more people. 

In the end, remember, if you are part of a large Scrum team, appreciate it! You are surrounded by different people which makes it the perfect surrounding to learn and grow. 

Besides learning more about coding and developing software, you will have a chance to sharpen your soft skills and learn how to be a better team player. After all, in Scrum there is no individual fault or praise, it is all about the team.

redesign candidate
BlogProduct Management
November 22, 2023

Finding the Ideal Redesign Candidate

When discussing software, arguments on what is visually and functionally "good" can be subjective. While UI/UX principles offer guidance, recognizing the need for a redesign goes beyond design standards. Decisions on starting a redesign are made based on the different perspectives of Engineering, Product Management and UI/UX, with additional factors…

Want to discuss this in relation to your project? Get in touch:

Leave a Reply