You're a Champion

Recently, my team embarked on a strategy/experiment designed to distribute the effort of driving features from inception through completion more evenly across the team. We noticed that both myself (Tech Lead) and our BA were overloaded. Too many features. Too little time. What’s worse, our developers were feeling out of the loop most of the time. They wanted more insight into what goes on before a story gets to development and more say in the direction of the team.

Thus, Feature Champions were born.

A Feature Champion is the champion of a feature throughout its entire lifecycle, naturally becoming the knowledge expert in that feature.

A Champion can be anybody on the team, though we chose to limit our Champions to the developers and QAs. It may sound like a lot of pressure, but that’s why the word champion is important. Champion != owner. Championing is not meant to introduce silos of knowledge or eliminate roles. Championing does not leave the champion alone to do the entire feature in isolation. Above all else, the Champion is a collaborative role that works closely with other team members and stakeholders.

So, what does a feature champion actually do?

• engages with team/feature stakeholders to gather requirements and priority
• takes guidance from BAs/QAs to help with business and quality analysis
• works with the PM/IM to track the progress and scope of the feature
• participates in architecture and technical discussions with the tech lead or architects
• presents the feature to the team as the knowledge expert
• acts as a touch person for questions about the feature from other teams

Notice the big thing that is not in this list: Does all the development on the feature themselves. No! You are a Feature Champion, not a Feature Owner. You guide the feature throughout its wonderful life, but rely heavily on support from the entire team along the way.

The Road Ahead

Some developers have taken to this exceptionally well - researching, scheduling meetings with stakeholders, writing stories, and asking tons of questions. Others have struggled with the less structured role. Championing some features involves much more than coming into work and writing code all day. Learning new skills is always difficult. It has forced us to prioritize our work. Now, a dev might be wearing many hats throughout the day, coding on a story for awhile, then doing analysis for a feature for awhile.

To outsiders looking in, it may seem like the team’s velocity would take a hit. While we have not done this long enough to tell for sure, I don’t think this will happen in the long term. I see the team ending up with more shared knowledge about the product, and more understanding of other roles. So, when the BA or Tech Lead win the lottery, the rest of the team already has the experience to step up and fill that gap.

Finally, I see Feature Championing as being a great way to build up less experienced devs in a safe way. They are learning what goes into analyzing a feature and interacting with non-technical stakeholders. They are thinking at a higher level technically about architecture and system design.