Writing independent user stories seems simple, but it is actually difficult to do well. There are often parts of some stories that are dependent on other stories' functionalities, so it's not easy to keep them separated. Kris Hatcher relates how his team wrote and scored stories to keep them independent but still meeting acceptance criteria.
The definition of done is an informal checklist that the team agrees applies to all pieces of work. But how does the definition compare to acceptance criteria? And should it apply to every task, or every story? How often should you review or change your definition? Allan Kelly helps you navigate your team's definition of done.
One of the benefits of agile is how it helps specify requirements. Instead of trying to predict the future with your requests, you can wait an iteration and see if more criteria are needed. This article gets into how executable specifications, specification by example, and test automation can help further improve your requirements management.
Acceptance criteria can be helpful in expanding on user stories in order to capture requirements for agile projects. However, acceptance criteria should not be a route back to long, detailed documents, and they are not a substitute for a conversation. This article tells you how and when acceptance criteria should be written and employed.
Specification by Example is a collaborative approach for constructing executable requirements. Examples demonstrate how the system should operate through the eyes of its users and shows understanding of the application’s functions. Michael Connolly demonstrates the practical and easy-to-implement Specification by Example method which he uses to write user stories and acceptance criteria. This direct approach, in which requirements are elaborated via executable code, creates a solid communication bridge between non-technical and technical staff and managers within the organization. Eventually, these executable requirements become the basis for the system’s acceptance test suite. As a take away, Michael provides participants with a lightweight requirements document format and an acceptance criteria framework to help you translate written specifications into automation.