Requirements Tracking for Product Quality

How product leaders develop a point of view on release readiness

Smoothly running customer-focused product teams have constant pressure to deliver releases.  There is value in helping the product team and stakeholders have a clear picture of the status of the release.  A good way to communicate a picture of the release status is by tracking requirements through the lifecycle.

Requirements tracking is often overlooked in fast-paced environments.  While there is widespread agreement that issues are harder to fix after a feature is released, taking a look at the requirements before release is frequently skipped.  With tools like Jira that are aligned to the product lifecycle, program managers can pull a report on the status of the requirements.  Plus there are multiple demos, test reports, and other validations of the release.  It is hard to add another checkpoint before releasing!

Let's dive into requirements tracking with minimal overhead and disruption.  While the pressure is high to deliver valuable features to customers, there are steps a product manager can take to efficiently track requirements:

1. Set up requirements for easy tracking

2. Monitor requirements through the product lifecycle

3. Summarize requirements before release

Set Up Requirements for Tracking

A hierarchy of requirements is key to easy downstream tracking.  A requirements hierarchy is tied to your executive summary of your product iteration.  Any subsequent tracking follows the hierarchy.

Suppose you are a product manager on a SaaS product that analyzes cloud spending for enterprises.   Your next release has these themes:

• New reports on cloud storage spending

• Chargeback information for large customers

• 50% improvement in time to generate a spending report

Working with your product team, you set up the requirements like this:

You have set up the requirements aligned with the overall themes in the release.  You use this hierarchy to review the detailed requirements with each team.  As each team accepts a requirement, you can begin tracking what you have and risk areas.  Additionally, as you review requirements, you stick to this hierarchy for any additions or changes.

Monitor For Changes

As the product team plans and develops the release, new information about what can and can't be done in the iteration emerges.  The new information comes out of the following:

• Design reviews

• Planning based on available resources

• New customer requests

• Priority changes

You are responsible for initiating the change based on the emerging information.  Don't wait for someone to ask you to change!  A product leader drives the change.

Taking the example further, let's see what happens on the release:

• Due to cloud API differences, the storage reports can only be developed for object storage

  • Your customers use mostly object storage - You move block and file storage reports to the backlog

• Your IT team is tied up and can't implement their part of licensing

  • Your business case is unaffected since new customers need the chargebacks

• Only one of the performance improvement use cases can be implemented

  • You decide to move the other use case to the backlog since you don't want to delay the rest of the content

Here is a summary of the changes you handle and communicate to your stakeholders:

Your requirements tracking hierarchy after these changes are as follows:

After collaborating on the changes, the product team continues developing the features.  Each scrum team demonstrates its results.  The final preparations for the release begin.

Summarize the Requirements Before Release

In the final push to hit the release date, no one is focused on the requirements.  As a product leader, you need to summarize for yourself how the requirements have been implemented.  Key reasons for you to prepare a summary of the requirements as delivered to the customers are:

1. To raise requirements issues before customers are exposed to the issues

2. To collaborate on release readiness

3. To communicate to customers about known issues

4. To evaluate the customer experience with the release

In the example case, here is what you find when you review the requirements:

• A storage report has a mix of units being reported

  • Engineering changes the display to be consistent

• The storage report takes longer to run than the performance required

  • Add this to the known issues in the documentation

• Documentation is missing on how to configure the chargebacks

  • A secondary release of the documentation is planned post-release

• Testing is not complete on the performance improvement

  • Notify stakeholders of the plan to test and the risks

As you review the requirements, you discuss your findings with the affected product team members.  Since you are asking questions and interested in how the release works, each team is happy to collaborate on what you find in the review.  The summary of the requirements after your review is below:

After the review and discussions, the product team feels good about the release.  Additionally, you have an easy way to update your stakeholders on the release readiness.

Conclusion

As a product leader tracking requirements is important to the success of your product.  Taking the time to do it right prevents issues from getting to your customers, keeps the product team aligned on plans, and validates cross-functional requirements well.

The steps to efficient requirements tracking are:

1. Make sure your requirements are easy to track

2. Keep an eye on your requirements throughout the lifecycle

3. Give a final check to your requirements before releasing to customers

Following these steps, product leaders work effectively with cross-functional teams to track requirements and develop successful products.

---