Back

Testable

When a user story can produce a definite pass or fail criteria, it is testable. Offering pass or fail conditions reduces miscommunication between roles. Developers and testers alike know what is expected of a feature, and clearly see whether it does what it was intended to do. Without this clarity, the team could waste time determining whether a user story is finished when they could be working on more features and adding more value to the product.

A user story should contain all of the work to make a feature work from start to finish. Backend changes must be grouped with their front end behavioral changes. Without a testable piece, a team cannot determine whether the changes have been successfully implemented. Plus, changes without adding features give no value to stakeholders.

As the backbone of Agile Software Development, user stories must be useful to offer value to a product and the team. This responsibility lies with the Product Owner. Whether the Product Owner writes the user stories themselves, or whether they allow other roles to write them, it is imperative that they only allow good user stories into the backlog. If a user story satisfies each of these discussed properties, it should give the team a good idea to work off of and to create a new feature for the product.

Recommended Further Reading

The following materials may assist you in order to get the most out of this course:

Translate »