Shorter time to market, increased developer productivity and improved responsiveness to changing business requirements are some of the reasons that are often given for forming an Agile software development team.
Avoid gaps in your user-stories for a happy development team.
User stories are intended to capture business requirements using a structured format. Typically, the format is: “As a given role”, “I want to do something”, “So that this outcome is achieved”. This covers the who, the what and the why. It’s concise and allows the requirement to be articulated by the business, using the language of the business.
However, it can leave scope for latent defects to persist in the requirements. A business user may overlook Quality-Of-Service (QOS) properties such as performance and required service levels. An Agile developer, with a keen eye on the team’s velocity might be tempted to ignore any requirement that is not explicitly referenced in the User Story. Such a situation is unlikely to result in satisfactorily for either party.
Acceptance criteria
One way to capture these important requirements is to extend the concept of the User Story by the inclusion of Acceptance Criteria or ACs to create a Well-formed User Story.
ACs are a series of statements that describe scenarios, values, system interactions and acceptable system responses. A Well-formed User Story is a comprehensive specification of the solution to be delivered that increases the chances of achieving the desired business outcome.
Organisations that are considering an Agile approach to software development should consider implementing a policy that results in only Well-formed User Stories being added to a backlog.
The use of well-formed User Stories will greatly improve developer productivity as not only does it describe the business requirement it also specifies precisely the characteristics that the solution must exhibit in order to considered acceptable to the business.