Creating User Stories for Scrum Masters
How Do You Create a Good User Story?
Valuable. All good user stories should have some business value. The customer is always at the forefront of agile so if there is no value for the customer, then why is it in there? Collaboration is important here. Scrum Masters should work with product owners to ensure the story has some business value.
Estimable. User stories should be scaled so that they are not too big or too small. Being able to properly estimate how long something will take is important and scrum teams should always have enough information to do so properly. Scrum Masters can help frame the scope so that user stories are properly scaled to include the proper information needed to estimate the story. They can also help define terms and clarify information that is needed so that the Team has the proper knowledge to estimate the story.
Small. A user story should always be small and be able to be completed in within the iteration. Scrum Masters can help determine if a story is small enough by looking at how long it will take to complete. Scrum Masters should know their developmental team well and knows what they are capable of. So if members of the development team are not available when creating a user story, Scrum Masters can help define the scope so it is small enough for the development team to handle.
Testable. This means the acceptance criteria should be clearly defined so that it can be tested. Even if there isn’t a test for it yet, it should still be able to be tested in principle. Scrum Masters can collaborate with product owners and team members so that user stories are clearly defined.
Typical Template
A user story can be written using a template that has three general parts: the title, the description, and the acceptance criteria.
Title: This is just to name the user story and should be used to differentiate it from other user stories. It should be very short (typically less than 10 words).
Description: type of user, goal, and reason/benefit. Typically, this follows a similar pattern:
As a <type of user>, I want <goal> so that <reason/benefit>.
● Type of user: is defined as whoever the user is. It is anyone who interacts with the system and receives the benefit. The type of user is who the product is being built for.
● Goal: is the ‘what’ of the equation. This is whatever the type of user above wants and is the intention behind the whole project.
● Reason/benefit: is the why. It is the value that is brought and the whole reason the product is being built.
Acceptance Criteria: Writing acceptance criteria helps define further the user story so that it can be tested. Acceptance criteria make sure that the Team’s interpretation of the user story matches the product owner’s and customer’s interpretation. These often grow and change as the product develops but are needed to clearly define what ‘done’ means. Scrum Masters can help define acceptance criteria, especially at the beginning, by guiding the Team when discussions happen with the product owner.
User stories don’t have to follow this template but following it often helps create simple and clear user stories that are easy to use. They should be short and be used to encourage collaboration. It shouldn’t be complex but instead should be an assurance a conversation will happen later.
Recommended Further Reading
The following materials may assist you in order to get the most out of this course: