This week, we changed the way we prioritize work within our Product team to focus on fewer concurrent features under development.

As our team has grown, so have our ambitions. Over the past 12 months, our Product team has more than doubled in size. So too have the number of epics (new features, architectural improvements, etc.) we’ve been undertaking concurrently. While for some developers it can be engaging to be the sole individual responsible for delivering a new feature into production, there are a number of drawbacks: features are only delivered as quickly as the individual can work, opportunities for knowledge transfer and pair programming are fewer, and the onboarding experience can be daunting (“dear new employee, please do this big hard thing on your own; ask questions if you get stuck”).

In short: we were doing too many good things at once. Following a discussion from our team retrospective last week, we decided to change it.

We decided to make progress against fewer epics (just 2 instead of 4–5). In addition to the knowledge transfer and onboarding gains, the primary benefit we hope to realize is reducing the time it takes for value to reach our users, decreasing the time it takes us to learn from our ideas meeting reality. Time will tell if this change will have the intended effects.

In the near future, we’d like to move toward a practice where every epic has assigned a Principal-level developer responsible for architecting the change, breaking it into issues, and leading its development to completion. As we scale up (i.e. from one Product team to many Product sub-teams) this construct should allow us to assign related epics to teams, assert the number of epics a team pursues be equal to the number of Principal developers staffed on a team, and surround Principal developers with multidisciplinary talent to minimize external dependencies.

By no means are any of these ideas radical or revolutionary. It is a hallmark of our organization’s development that we felt this tension now, and needed to make the change.

The summer slump appears to be over as we see green lights across the board this week. Most significantly we’re seeing clear increases in user registration growth, MAU, and a big jump (12.5%) in the number of week-over-week meetings ran.

…made great progress on our Retrospective grouping helper. When a team has dozens or even hundreds of bits of feedback to sort through, grouping can be a real challenge. We’ve been working on this feature for months, and it’s getting closer to completion. Here’s a in-development gif (note: the UI isn’t close to the pixel perfection of our designs, yet):

…developed some new tooling to make it faster to spin up private instances for our customers. The number of single-tenant instances Parabol has sold to Enterprises has tripled within the past few months. Our new tooling will make enabling these instances much easier on our end, as we anticipate providing more of them for our customers.

…launched a survey on what metrics agile team leads and scrum masters measure. We will share what we learn!

…Experimented with a few different tweet formats: a meme, a product gif, and a quote retweet with a link to a resource.

…wrote, recorded, edited, & posted 2 new TikToks: a #learningtok about even/over statements & an ice breaker question.

…designed some initial ideas for how GitHub labels will work in Sprint Poker.

…wrap up sprint #87.

Have feedback? See something that you like or something you think could be better? Leave a public response here, or write to us.