Lots of software gets built with less than perfect requirements. The results are typically less than ideal. Requirements need to be clear and precise but there’s more to delivering a high quality feature than just making sure all the requirements are met. A review process ensures that what gets built meets the outcomes the business is looking for. Those outcomes can be monetary (reduced costs, increased revenue), technical (lower error rates, better scalability), customer-facing (happier users, increased conversion) or anything else in between.

Putting such a review process in place is an ever-evolving process. Every feature that is built will help to refine and hone the review process. People from every part of the organization need to get involved to ensure that every feature that is delivered brings the highest value possible to the product. The following is a series of recommendations on what should be reviewed by the different teams that work on a product.

Product Management Review

The product team typically takes an idea from its inception to something that is close to being ready for development. There’s a few key items that need to be reviewed before presenting an idea to the development team:

• Why is this feature important right now? Are you trying to beat a competitor to the market or play catchup? If it’s the fomer, you’ll want to focus the feature down to its minimum viable product so you can ship as quickly as possible. If it’s the latter, you’ll rather want to find a way to differentiate your offer from a competitors.
• Does this feature provide the highest business value? How are you measuring that value? A no answer to highest value question might mean it’s time to re-evaluate when the feature gets done.
• Does the feature fit with the short and long term vision of the product? A ‘no’ answer to either of these goals should lead to questions about why this feature is being considered for development.
• Which business outcomes will be achieved by building the feature? Knowing if you’re targeting higher conversion rates or increased customer satisfaction will help the development team focus their efforts where it matters.
• Are the UX and design requirements well understood? Is it achievable to build the ideal solution now? Do you even know what the ideal solution is?

Once that’s done, the product team still needs to be hands on during the build phase of the feature and re-evaluate as the work starts to take shape. It may be time to re-evaluate the feature if any of the key drivers of the feature become significantly compromised.

Architecture Review

Whether a team does its architectural review by committee or has a single person overseeing it, the objectives remain the same. The answers don’t have to be complete but a minimum level of direction for the development team is should be provided. Here’s what should be considered from that perspective:

• Does the current technology stack give the development team everything they need to accomplish the work? Are there any other technologies that could be more appropriate to solve this problem?
• Are there any products on the market that can accelerate development by cutting down on some of the heavy lifting? As an example, you wouldn’t build your own search engine. You’d start with an existing search engine and build your own logic on topic of it.
• Is there a different way to achieve the goal of the feature that might be more realistic considering the current technological reality of the team? A typical example of this would be to use a cloud provider’s custom authentication scheme which would be much faster than implementing an OAuth authentication scheme. At the end of the day, an end-user won’t be able to tell the difference.
• Are there any risks to doing the work now? Will the team be incurring technical debt that could be reduced if the feature is done later?

Development & QA Review

I’m lumping these last two together since testing is increasingly becoming an integral part of the development process. This review needs to happen at two distinct times regardless of your development methodology.

The first review occurs before any work is done:

• Are there any outstanding questions that need to be resolved before work can start? Product Management should be available to provide answers to any questsions that come up — and there are likely to be many if this is the first time the development team is hearing about it.
• Are there any alternative ideas that might achieve the business outcome in a similar but faster way?
• Are all the needed components to solve the solution well understood? Is any research needed before development can start?
• Is everything required to properly test the feature available?

The second review happens once the feature is complete and ready to be delivered to customers:

• Are all the feature requirements met to the satisfaction of the product team?
• Does the code comply with all the standards of the team?
• Has any technical debt been accrued? Has it been tracked in a separate issue?
• Are there any gotchas where the user might get tripped up when using the feature? Can anything be done about it?
• Are the happy path and most common failure paths thoroughly tested?
• Has enough of the feature been covered by automated and manual tests?

A good retrospective can help a team identify what is and isn’t working well in the development process. In fact, it’s the most valuable type of review that a team can do because it allows the entire team to get on the same page.