Structured Requirements Made Easy
Best practices for organizing requirements for success
Are you concerned that your product team isn’t implementing your requirements? Are your program managers driving the implementation or do you need to micro-manage the implementation? If you need to micro-manage the implementation, then your requirements are not structured for product team success.
Some of the signs that your requirements have a poor structure are:
You are getting many questions about the purpose and benefit of the requirements
Your product team isn’t planning the implementation
Your product team is working on low-priority requirements
Your stakeholders don't know the status of the in-progress features
If you are having these issues after working with your team to get commitment to requirements, then you might be missing structure in your requirements.
What Are Structured Requirements?
A clear hierarchy of requirements going from features to epics to stories is the hallmark of structured requirements. The other keys to structured requirements are:
Description: clear explanation and measurable outcome of the requirement
Context: what is the reason and background for the requirement
Traceable: linkage of the requirement to a shared goal
Acceptance criteria: how to validate that the requirement was implemented
Additionally, these requirements are easy to find in a shared space that the product team and stakeholders use.
Structured Requirements in Action
Ideally, you want structured requirements from the beginning. But you can add and change the structure through planning and development.
The main users of your structured requirements are:
Your stakeholders
Your product team
You and other product leaders
Your structured requirements are used to communicate about feature status, business case impacts, and customer experience.
The above diagram shows how these different users learn about your structured requirements.
As your product iteration goes through the phases of concept to planning through delivery, the below diagram shows how you communicate your structured requirements.
Setting Up Structured Requirements
As you review new concepts with your stakeholders, you can set the stage for structured requirements. This lets stakeholders easily monitor your work with the product team on bringing the requirements to market.
Below is a format to outline a new concept and requirements structure to your stakeholders:
Building on the executive summary, you can prioritize your feature requests using the below format:
As your requirements are defined, then you can communicate about the teams and the plans for each feature. Here is an example:
After you have reviewed the requirements and worked with your program manager on finding teams to plan the work for each story. It is time to let the program managers and delivery teams do their work!
Tracking Structured Requirements
Your requirements structure and acceptance criteria come in handy during development for:
Coordinating demos or other service readiness checks
Evaluating readiness to deliver
If you don't already have structured requirements, you can introduce them in the demo planning or in your assessment of release readiness for customers.
Let's review an example of using your structured requirements as you assess readiness to release:
In this example, you have summed up the changes from the development of three example features. Below is how you summarized the requirements and risks.
For more information on this example, please see the requirements structure for development through delivery.
Conclusion - Structured Requirements Made Easy
Putting in time to structure your requirements, saves time communicating to stakeholders and product teams. You can articulate the value of your requests and lead your team to deliver features that your customers want. By structuring your requirements with the end state in mind, you can adapt to changes as you go and efficiently lead your team to delivery success.
The best practices are:
Structure requirements from the beginning
Adjust the structure as you go
Communicate using the structure to your stakeholders and product team
After the plan is locked, use change management for structure adjustments
Use the structured requirements throughout the lifecycle
Structured requirements help you lead more efficiently, head off feature delivery issues and effectively communicate about your product's features during development.
Link of the week
Layers of complexity can get in the way of product strategy Look at your strategy process from different directions to avoid pitfalls. @Nacho Bassino provides a podcast with Randy Silver and his takeaways on why strategies fail.
Super helpful post Amy. We've been pushing hard on building out or at least being able to share a metrics hierarchy that roll up to our organizational goals - in line with your traceable notes. When I read others, I really get a quick sense for the angle they're taking with the work which helps me better understand it as well.
Great point that metrics can align to requirements ! Thank you!