Running multiple sprints
I am managing a team of 6 software developers ( 3 frontend/FE and 3 backend/FE). They tackle PBIs in pairs of two (1FE and 1 BE). Because the product is matured enough, the pair-team works on independent features or functionalities.
- 1st pair - "Update the KYC flow to onboard newly registered users"
- 2nd pair - "Integrate with a 3rd party headless e-commerce solution for the ease of existing users"
- 3rd pair - "Integrate a 3rd party chat platform which allows users and sellers to chat with each other"
Each use case has about 8-10 PBIs and an estimate of 7 man-days per case.
Due to budget constraints, I am unable to have smaller scrum teams ( 2 devs + 1 QA + 1 PO + 1 SM). Instead it is currently 6 devs + 1 QA + 1 PM (me) + 0 SM
My questions are as follows -
- What does the Scrum Guide say about multiple sprints running parallely ? So, in my case, when one pair-team is done with their release, they pick up a new feature to release, while the other two pair-teams might be in different stages of the scrum cycle. How flawed is this practice ?
- Since the product is matured enough, what one pair-team might be working on has none to minimum impact on the other pair-teams. Because of that they are often not in the same sprint cycles. One might be preparing to release while the other might be just starting. Given this situation, would it be better to hire 2 more POs and QAs and have smaller scrum teams?
I am happy to answer any questions to clarify my situation in more detail. And I thank you in advance for your feedback.
Scrum uses empiricism to establish control in complex situations where more is unknown than is known. What outcomes are you hoping to achieve by using Scrum in the situation you describe?
Going to start by sharing you a link to the Scrum Guide. It is free to all and this is the official source for the guide. It is available in many languages
What does the Scrum Guide say about multiple sprints running parallely ?
Absolutely nothing. In the Scrum framework, each team operates individually. They are self-managed, self-organizing. Each Scrum Team decides their own cadence and processes using the framework to guide them. According to the Scrum Guide, there is no expectation that they all Scrum Teams in an organization use the same cadence.
Remember that Scrum is a framework and not a methodology or project management tool. So process is not a part of the guidance. So your organization can choose their own process. If one is that all teams must execute on the same cadence, there is no "Scrum reason" that you can't.
Given this situation, would it be better to hire 2 more POs and QAs and have smaller scrum teams?
In the Scrum framework, every Scrum Team has 3 ROLES. These are not job descriptions, they are roles. As long as you have someone on each team that is fulfilling the responsibilities of the roles, you have a Scrum Team. However, the team of teams that you describe doesn't really fit the suggestion for a team from the Scrum Guide. (https://scrumguides.org/scrum-guide.html#scrum-team). As you have described the situation, you aren't following the Scrum Guide.
In researching answers, I see that multiple teams can run on multiple schedules and that by doing so that just increases the complexity of the release train. I'm interested to see what others thoughts are on this. I previously worked for a company that moved everyone to the same sprint cadence and schedule and saw how much easier that made PI planning because all teams knew what the sprint dates were and when they could deliver dependencies for other teams. If a company is large, I don't see why they wouldn't want to manage this way and have multiple sprint schedules with no real alignment.
Do you think companies that have all teams on the same sprint schedules produce more consistent results than those that have to account for dependencies on teams with different sprint schedules?
@Sharon,
You are using terminology that makes me believe you are in a Scaled Agile Framework (SAFe) organization. While there are some similarities to Scrum as defined in the Scrum Guide, SAFe using a version of Scrum (ScrumXP) that they have modified to fit within their framework. Also because their framework is used to scale across multiple teams, the explanations we have given before are not applicable. While SAFe does not require all their ScrumXP teams to synchronize on individual Sprints, they do have required synchronization points centered around planning and delivery. In all of the situations I have information about, synchronizing teams to same cadences does make things easier. But I have also heard of occasions where some teams were more efficient when they operated on different cadences.
As with anything agile, the real answer depends on the organization, teams and the processes that have been put in place. However, I do advocate that unless there is a strong reason, don't change things if they are working.