Requirements Refinement Process

The process for defining and refining requirements will vary by project, but in terms of how a typical project might operate:

1. In most cases, Product Backlog Items will already exist as per the backlog defined at Sales/Discovery stage. However, these will generally lack the full detail required to be able to deliver the work item.
2. As an acknowledgement of the above, it is recommended that the Audacia Project Manager marks all work items with the AC not signed off tag to reflect that these are not ready to be worked on.
   1. It is recommended that a tag colour scheme is configured in the Azure DevOps project board such that these are highlighted in red, while the AC signed off tags show in green.
3. The Product Owner should be prompted to start adding detailed acceptance criteria to these work items, to help flesh out the detail of what is required. This should be done based on the prioritised backlog order i.e. imminent cards should be defined first. This exercise should happen on an ongoing basis, and can be initiated offline.
4. Once the Product Owner has done a first pass on defining requirements, they can tag the card to reflect this e.g. a Ready for review tag might be used for this.
5. On a regular basis, the Audacia Project Manager should review the cards with the Ready for review tag. They should capture any queries in the Questions and Clarifications field and send an @mention to the Product Owner to prompt them to respond to queries.
   1. They may choose to do this as part of Three amigos sessions that involve a developer and test engineer, since engineers will be able to offer insights that the PM will not.
6. The Audacia Project Manager should set up regular Requirements Refinement sessions with the client Product Owner.
   1. For a typical project this might involve running two 45 minute sessions each week - though of course this can be adjusted based on the volume of work items that are not signed off.
   2. Dependent on circumstance, it may also be necessary to invite client Subject Matter Experts and/or an Audacia engineer to these sessions.
   3. These sessions are an excellent opportunity to coach the client Product Owner on how to express requirements in such a way that best facilitates delivery of the required functionality.
   4. For each work item reviewed, the outcome might be:
      1. The Product Owner and the Audacia Project Manager agree that the work item is well defined and can be marked AC signed off.
      2. The Audacia Project Manager might be content that work is well defined, but they may ask to run this by developers/test engineers prior to agreeing sign-off.
      3. If open questions are captured, the Product Owner might agree to take this away and close off any queries prior to agreeing sign-off.
7. Note that prior to signing off a work item, the Questions and Clarifications section should generally be blank.
   1. By this stage, the answers to all questions should either be reflected back into the acceptance criteria, or converted to a statement within the description. This minimises the number of locations that a developer or test engineer needs to review in order to comprehensively understand the requirement.
8. Once the each Product Backlog Item is marked AC signed off, it is now ready for estimation as part of the project’s regular estimation sessions.

User story mapping

A user story map involves representing work items in a chart in the order they must be delivered.

This can be an incredibly useful tool for:

1. Helping the client Product Owner to identify gaps in requirements.
2. Helping us understand where to focus energy first in terms of refining and signing off requirements.
3. Understanding the dependencies that must be met before a work item can be delivered.
4. Planning the delivery of work in the scenario where multiple developers are working on a process in parallel.

This technique is strongly recommended in the case where a larger team is working together in one area of the system, or where the business workflow is complicated.

Example:

In the above example, we can instantly derive the following useful pieces of information:

1. Delivering #125 is a priority, because all other work is blocked until this is complete.
2. It may not be practical for multiple developers to deliver this work in parallel, due to overlapping areas of work. However, once #125 is delivered then #126 and #127 could be worked on by two developers in parallel.
3. Sprints should be planned in such a way that acknowledges the above i.e. the start of development for #129 should be planned to coincide with completion of both #127 and #128.