Dividing a Product Engineering Sprint Team
VP Product at Startups
In my organization we work on two general types of projects. They can be thought of as revenue-enhancing projects and cost-reduction projects, or customer-facing experiences and internal-facing experiences. What I found was that it was hard for us to track the amount of resources we were spending on one versus the other. We were all working as one big scrum team, and it was hard to gauge when we were overinvesting in one area at the expense of another. We wanted to make sure that we could manage the amount of investments we were making on the two sides of the business. In addition, a large team working on a variety of projects led to unnecessary overhead related to prioritization, sprint planning, and project management.
Working closely with the head of engineering, we decided to split the group into two separate, dedicated sprint teams. In order to do this, we needed to determine who would be on what team and what the teams would work on.
On the Product side I decided that we needed each team to have a fully dedicated Product Manager on each team so that they could manage the overall customer experience and prioritization. On the design side, we considered having dedicated designers, but given the variation in projects, I decided that it would create too much of a bottleneck when a particularly large design project prevented other work on that team. Designers would be assigned to projects rather than teams.
On the engineering side, there were two more experienced engineers who took the lead on making a recommendation on assigning engineers to each team, taking into account skills & preferences, but with the goal of creating balanced full-stack teams. After discussions with the engineers, they recommended a team structure that we approved. To address concerns of future growth for individual engineers, and shared expertise for the entire code base, we agreed that engineers would have the opportunity to move between teams over time.
Now we had our teams, and we needed to distribute the work. Each team was dedicated to specific areas, but I knew that we'd need to have some flexibility for the movement of initiatives and projects between teams. While in general we had one team working on consumer-facing experiences and the other on internal-facing, there were many projects that touched both sides. For these, I decided that they should be assigned to the lesser booked team. This provided additional flexibility to balance overburdened teams and provided opportunity for engineers to work on other areas of the code base.
- The overhead of managing one large team wasn't obvious until it was eliminated. The entire team was spending time to understand all the work, even though less than half of it was relevant to them. Now, teams focused only on their projects. They spent the same amount of time, but used it better. They went deeper into strategy and planning, were more engaged, and improved their productivity.
- The split made it immediately clear where we were under-allocated: we were two weeks behind in one group while a little bit ahead in the other. So once the teams were broke in two, we could shift some projects and rebalance.
- We did have had to make some difficult trade-offs. With increased visibility on our resources, smaller projects were harder to "slip in" because it was immediately obvious that they were taking the team away from other higher priority items.
- Prior to this change, it was hard to predict how long a project would take, or what the opportunity cost would be. Now, it's clear what other projects will be delayed and it's easier to plan.
Be notified about next articles from Meghan Cochran
VP Product at Startups
Connect and Learn with the Best Eng Leaders
We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.