When Are Agile Requirements Ready For Development?

As a product owner on an agile development team, I am responsible for populating the product backlog with a list of user stories to communicate the product direction.  In layman’s terms, a traditional lengthy requirements document is broken down into small parts that are formatted into a simple story told by the end user in hopes that anyone should be able to comprehend.  For example, “As a product owner, I need to add an attachment to a user story so that mock-ups are available for team members to reference.”

By design, a user story will force collaboration among the team members and ultimately increase the chances of a successful sprint iteration (not to mention invoking feelings of a shared product vision.)  If ample time is allotted for effective collaboration, user stories should be reviewed with part of OR the whole team PRIOR to sprint planning.  The goal is for development (and the rest of the team) to ultimately determine when a user story has all requirements ready for accurate tasking and estimation to occur.

All of my user stories have a lifecycle and the status includes ‘In Planning’, ‘Requirements Ready for Development’, ‘In Development’, ‘Ready for UAT’ and ‘Ready For Release’.  In this posting, I am focused on ‘Requirements Ready for Development’ which means the user story should have all of the information you and the team thinks they need in order to provide accurate estimates. Below is a proven requirements checklist that should keep teams happy and less frustrated with incomplete requirements. Very important to note that each user story may NOT require all items in the checklist. In fact, including too much detailed requirements documentation is dangerous and can defeat the purpose of choosing an emergent iterative design process.

Possible Requirements checklist:

• User Story format is complete (role, desired feature and business case) *at minimum required
• Conditions of Satisfaction *at minimum required
• Communicate the Database Structure
• UI/UX Design (initially wireframes or mockups)
• Business rules including role based access control lists
• Workflows and triggers
• Acceptance Criteria (continuously refined during the sprint)

The Product Owner and stakeholders should be able to complete the user story format and conditions of satisfaction.  Conditions of Satisfaction (COS) may be a bullet list of items the user should be able to do if the story is implemented.  You can also think of COS as the ‘definition of done’ which allows the team to understand the work required to finish the story.

The rest of the checklist items should be reviewed with the team so much time is not spent on documentation that willnot be read or even looked at by the team.  Communicating the database structure can be as simple as  including exactly what the input type looks like in the design or wireframe.  If needed, include a markup comment next to the field to include max char length or lookup table values to select from.  Workflows and triggers can also be included in the design or wireframe but if the instruction is complex enough, trace out the paths using data flow diagrams for precision.Business rules are especially important to document in a single on-going list and attach updated versions of the list to the user story.  If different lists are maintained, it is easy to miss when one business rule modify’s or contradicts another.

In conclusion, it is the responsibility of the whole team to decide when requirements are ready for development.  The extent of which you choose to document requirements may depend on the structure of your whole team.  Most teams have at least a creative designer to deliver the look and feel requirements.  If the team is moving faster than the creative resource can deliver, then the product owner and the team must collaborate and compromise often enough to come up with a good way to perform acceptance tests on the features via a user interface.