Posted by SCRUMstudy® on November 07, 2022
Categories: SBOK® Guide
User Stories adhere to a specific, predefined structure and are a simplistic way of documenting the requirements and desired end-user functionality of a product. A User Story describes three things about a requirement—Who, What, and Why. The requirements expressed in User Stories are short, simple, and easy-to-understand statements. The predefined, standard format results in enhanced communication among the business stakeholders and better estimations by the team. Some Epics/User Stories may initially be too large to handle within a single Sprint. Once Epics move up in the Prioritized Product Backlog to be completed in an upcoming Sprint, they are further decomposed into smaller User Stories.
A User Story is a casual document of requirements that can be used to develop acceptance criteria. Acceptance criteria are usually determined by the Product Owner in partnership with the customer for use during the Sprint Review meeting to make sure each deliverable meets the customer’s needs before implementation.
There are many benefits of using User Stories:
As a <role/persona>, I should be able to <requirement> so that <benefit>.
As a Database Administrator, I should be able to revert a selected number of database updates so that the desired version of the database is restored.
Instead of having the requirement like this: the doors should be at least 3.34 feet wide and 7 feet tall, the pathways must have a clear way of at least 5.4 feet, a User Story expresses the need this way: resident service personnel must be able to transport the service carts already in use anywhere in the building without any obstruction so that the service cart is used by all occupants.