What is the development team process for creating User Stories and creating the deliverables? What role do the Scrum Masters play in this process?
Creating Agile Requirements
A 59 Seconds Agile Video Animation
Creating User Stories for Scrum Masters
A 59 Seconds Agile Article
Creating User Stories: How Do You Create a Good User Story? Valuable
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.
Creating User Stories: How Do You Create a Good User Story? Estimable
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.
Creating User Stories: How Do You Create a Good User Story? Small
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.
Creating User Stories: How Do You Create a Good User Story? Testable
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.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
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.
User Stories Applied
A 59 Seconds Agile Book Review
User Stories Applied by Mike Cohn is one of our favourite books. The book starts with an overview into user stories, and details what they are and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the requirement objectives are met. Next Mike gives an in depth discussion of who they are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.