Defining User Focused Requirements

Requirements should provide all information necessary to develop a feature as the envisioned by the author to ensure team's deliver the desired result. In order to achieve this, at a minimum requirements should include a user story, acceptance criteria and technical requirements, and where appropriate, out of scope items, final designs and copy, and any other relevant documentation or linked tickets.

To ensure the requirements effectively capture user value, they should follow the INVEST criteria:

• Independent: You should be able to play this scenario in any order; if the ticket requires another ticket to enable it, one or both of the tickets are no longer independent
• Negotiable: The requirements should focus on the desired outcome but still allow room to negotiate the detail of the solution as it's been developed
• Valuable: It should provide value on its own, moving you measurably closer towards your goal even if may not be a shippable feature in it's own right
• Estimable: In order to accurately prioritise and plan work, you need to be able to estimate the complexity of a scenario compared to other scenarios. An inability to estimate the work suggests that the requirements are not yet fully understood
• Small: You should aim to constrain the scope of work to what can be completed in a couple days, with an upper bound of one sprint. The larger the story, the less likely you are to fully understand the work involved, and therefore the more likely you are to have undesirable outcomes or delays.
• Testable: You can only consider a feature complete if you are able to verify it has been built as specified. If you are unable to determine how to verify the requirements have been met, it suggests that you do not yet understand it well enough.

Typically written in the format of "As a user, I want {action}, so that {outcome}" (also known as role-feature-reason), a user story frames the requirements from the user's perspective of a scenario. If a scenario cannot be framed from the perspective of providing value to a user, that should be a trigger to consider whether the story is appropriate and ready to be defined.

Acceptance criteria define the user interactions related to the requirements and serve as the basis for testing. Like a user story, it uses the formula of describing the precondition, action and outcome, typically using the syntax "given {precondition}, when I {action}, then I {outcome}" (also known as gherkin syntax). When defining the interaction, it's important to describe what is being done without being prescriptive to how it should be done.

Technical requirements detail implementation details, such as required libraries and target versions, database schemas, and API contracts or contracts between application layers. Although defining contracts seems to oppose negotiability, contracts themselves should be independent and negotiable, and can serve as the basis of the unit tests written as part of development, which is especially important when employing test driven development.

Out of scope, further information, designs and copy are all optional dependent on the scope and needs of the requirement, but in a general sense should be any additional information required to build out the requirement as envisioned, and serve as or link to the source of truth for what is being built.

Thoroughly defining the requirements of a feature is essential to accurately and efficiently building a product. By following these guidelines, development teams can accurately prioritise and plan work while ensuring that the end product meets the user's needs and expectations.