Bicycle or 18-Wheeler: Shared Understanding Through Feature Reviews

You may have seen comedic drawings that show the evolution of what a customer asks for versus what is built. A common one depicts a sequence starting with a wooden tree swing and ending with a tire swing, with various absurd options in between.  

Or imagine, the customer needs a vehicle that can go on a highway, but no one knows what that means. Ideas abound: The customer wants a Rolls Royce but needs a mid-sized sedan; stakeholders want a stretch limousine; and team members have opinions varying from SUV to motorcycle, to 18-wheeler to bicycle. 

All parties need a shared understanding of the customer's goals and needs, but how do they get there?

It's a key responsibility of Product Owners (POs) and Agile Business Analysts (ABAs) to understand the business and customer needs and communicate those with the development team so they can build something extraordinary to satisfy these needs. Such communication is not easy to do. 

Understanding the customer's needs

Misalignment between what the customer needs and what the team understands will cost time and money. That is not an exaggeration: As described in this article, misunderstanding what the customer needs increases expenses, creates delays and impacts quality.

Therefore, it makes sense to start with a shared understanding of the customer's needs instead of discovering later that the product built doesn't meet those needs.

Holding Feature Review (FR) events is one strategy that helps improve alignment and understanding of upcoming work before development begins on your project. FR events help encourage open discussion on a new feature, a particularly complex part of a more significant feature, or a capability that may need to be broken out into multiple features. 

Case study: Clarifying a complex feature

As an ABA, I worked with a development team that had begun a key feature to the application we were building. This feature was so important that the application's main use case wouldn't work without it. It had to be done right; imagine if the software were a motor vehicle, this feature was the engine. 

The concepts and business logic were complex. The PO, Tech Leadership (TL), and I observed that team members' understanding of the work was inconsistent, despite refining various stories for this functionality with the team. We realized that no one (including us) had a holistic view of the work from end to end.

Planning the Feature Review event 

To better help the team understand what the customer needed, we started with ourselves: PO and ABA, TL plus our User Experience (UX) designer.

Feature planning starts with this group researching the business and user needs to be addressed by a particular feature:

• We met to see if they have enough information to present the feature to the development team. That is, we made sure we were aligned on the customer and business needs for this feature amongst ourselves before helping the team understand the feature.
• Then, we scheduled an FR event and invited the development team and customer stakeholders. We told them we would review the business requirements, feature acceptance criteria, UX mocks and diagrams that showed the user steps and data flow from end to end.
• It took us a couple of hours to plan the FR agenda and plan how to communicate most clearly with the team and customer stakeholders who would attend.

The process we followed to run the FR meeting (shared below) is not set in stone. You might follow a different approach for reviewing a feature with the development team and gaining a shared understanding. The only requirement is to do this work when the team needs it or before, typically between requirements discovery and writing stories.

Running the Feature Review

The case study FR event included the entire development team, product ownership team members, TL, UX designer, as well as key stakeholders and subject-matter experts who were not on the development team.

The meeting followed this pattern, which we used in future FR events on this team because the first one was so successful: 

1. PO reviews the business goals and feature-level acceptance criteria using visual media (PowerPoint, Mural, etc.).
2. If the work involves user interface changes, the UX designer or PO reviews mocked screens or prototypes. Ideally, the mocked screen should have gone through end-user testing first. Assume the screens may change as a result of the conversation, but this imagery will help everyone move towards the same understanding.
3. ABA walks through a business process flow to help the team see the overall process and context of the work.
4. The Development Team discusses technical considerations and the best way to begin working on this feature.
5. If time permits, the team can write the first few stories needed to prioritize and start the work.

This pattern is flexible, depending on what's needed for the particular feature or team. For example, if there are no UI changes in this feature, you would skip step 2. 

Feature Review outcome

In our FR, it took about two hours to review and discuss the feature in-depth. We spent most of the meeting focused on the development team, ensuring their understanding of the problem to solve and letting them discuss the best way they saw to approach the work. 

In the end, the FR event had these impacts on the group:

• The development team aligned on the scope and purpose of the feature, which enabled them to agree on how to move forward with the work.
• The team had the opportunity to ask questions of stakeholders and subject matter experts during the meeting, removing some ambiguity that might have slowed down the work later.
• At the same time, the stakeholders gained insight into how the team was thinking about the work and could offer insights about dependencies and other information the team didn't have yet.
• The team seemed happier and less worried about their success with this feature. They knew how to begin and could speak about the feature with more confidence.

This FR became the first of many for this team because they recognized the value of starting each project with an in-depth review meeting like this one.  

Stakeholder attendance at the Feature Review

Stakeholders are invited to the FR meeting to observe, ask questions and provide additional business or technical insight if needed. Inviting stakeholders exposes them to the concepts and scope of work from the start. Early alignment should help stakeholders create a realistic mental picture of what the team will build.

To ensure this mental picture remains realistic, be aware of how familiar your stakeholders are with agile development principles. If they are not familiar, they may not understand that development teams discover new things as they work and may have to adjust their plans. Make it clear to the stakeholders that the goal of the FR is not to set a plan in stone; rather, it's to make sure everyone in the meeting shares the same understanding about the feature based on the information available at that moment. 

While having stakeholders at the FR is important, it's critical for the PO and ABA to keep the conversation on target and make sure stakeholders or other attendees do not introduce new scope or otherwise derail the conversation. If the FR event feels like it's going in a direction that doesn't support gaining a shared understanding of the feature scope and goals, it's appropriate to stop the meeting and acknowledge the FR event may need additional preparation and rescheduling.

Summary

We laugh at the idea of a customer needing a mid-sized sedan and getting an 18-wheeler instead, but such misalignment is no laughing matter. It costs businesses time and money if product ownership and the development team misunderstand the customer needs and goals before work on a feature begins.

Feature Review meetings are powerful tools to help the development team and stakeholders gain a shared understanding of what's needed.