There is an art to writing Requirements into User Stories. Much of the literature on User Story requirements discusses the Product Owner as the crafter of Epics, and often User Stories.
- The Product Owner has typically Worked for the Company for a number of years and understands the Stakeholders.
- In turn, the Stakeholders understand him. That makes it much easier for the Product Owner to collect the information required for User Stories.
- He can also determine specific employees who have the required knowledge to add to a User Story.
- He understands how the Company Works and the Organizational Culture. The Product Owner also knows the Company Policies, Processes and Procedures.
” You Can’t Always Get What You Want,
If You Try Sometime, You Can Get What You Need”
Mick Jagger and the Rolling Stones
Crafting User Stories from Requirements
This does not mean that the remainder of the Scrum Team (Scrum Master and Development Team) must be left out from crafting User Storie. When it comes to crafting Epics, which are the broad themes of the Product description, it is probably best that the Product Owner is responsible for getting them Done and then Communicating them to Stakeholders and Team members.
User Stories are obtained by breaking down an Epic into its most granular type. The User Story generally explains a single activity within that Epic. With the overview supplied by the Epic any Development Team member should be able to get the information required to compile a User Story in Collaboration with one or more Users who the Product Owner has identified. There are many ways of getting the information Required, and the Scrum Team members are not limited to Face-to-Face Interviews.
Tools and Techniques.
User Story Requirements -Interviews.
It is an unusual trait of Human Nature and our desire to be social beings that, when asked a direct question, we will frequently reply with an answer that we think the questioner wants to hear, instead of our own Opinion or View. This is among the most significant Risks in collecting information. If you are Interviewing somebody, you should take care not to Frame Your Questions in such a Way that you get the answer you were trying to find. A Valuable technique for inviting the Interviewee to put forward his own opinion is using Open-Ended Questions.
An Open-Ended Question can not be responded to with a “yes” or “no”. It needs to be worded in such a way that we show empathy to the Interviewee. We Value his input and understanding and do not try to enforce our opinions, but stay neutral.
- Open the Interview with a quick explanation regarding what the purpose of the Interview is. Detail how you believe that your Interviewee can offer Valuable info. You should make it clear that they are the professional and you understand little about their Area of Expertise.
- Start with a broad concern about the Day-to-Day Processes and Activities that the User is included in. For example their day-to-day processes as a call-centre operative. If you are composing a User Story, it will be about just one of the activities. This sets the context.
- Pick a significant point and ask specific questions. For example, ask what actions they undertake to start their day. This might be your first User Story.
- Ask how they would improve the existing method of operation (how it could be).
- Summarise what you have Learnt (your User Story) and ensure that the User agrees with the detail.
- Ask what would be proof that the Agile User Story has been Developed correctly. To put it simply, what are the Acceptance Criteria?
- Thank your Interviewee and terminate the Meeting.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
User Story Requirements – Workshops.
A Workshop is a great way of getting a range of input and viewpoints. The Workshop is likewise a terrific Change agent for keeping Users included in the Agile Project. This aligns with the Values and Principles of the Agile Manifesto.
User Story Requirements – Observation or Work Study.
This can also be helpful where you have a large User Group (like a call centre), where you can only Interview one or a few of the Users. You can also utilize Questionnaires to gather details from all the remote work locations, which is a lot quicker and cheaper than visiting them.
User Story Requirements – Questionnaires.
Questionnaires are a beneficial way of collecting extensive details from a large group of similar Users. Take care to keep the questions as neutral as possible. You can then collate all the details. Redistribute the collated info, either for discussion in a Meeting or by means of a Round Robin Process utilizing email.
If you Plan on utilizing Questionnaires, it is best to utilize them for an Epic or several Features or User Stories, so that you gather the maximum information with the minimum level of interruption to the Users’.
Evidence of Concept.
User Stories must be Critiqued and Tested. This can be Done in Scrum Team Workshops. The goal would be to:-.
- Test whether the User Story makes sense on its own.
- Assure that the Acceptance Criteria are Measurable and will Satisfy the User expectations.
- Validate that the User Story aligns with the other User Stories comprising the Epic or Feature.
- Commit to the Stories in preparation for the next Sprint.
Writing User Stories is an art, and gets simpler with experience. Instinct is Required to determine whether your Customer has told you what they need and not what they want. You do not wish to replicate the legacy Product, which can occur if you serve as a scribe when crafting the User Story, instead of applying important yet objective questioning to the information you have gathered.
The ‘Agile Scrum Master Training Course With 59 Seconds Training‘ is now available for free. This free Scrum Master Certified Online Training Course provides an in-depth understanding of the Agile Scrum Master roles and responsibilities, where you find out what a Scrum Master does and how to do it. During this free course you will learn all of the tools needed to succeed as an Agile Scrum Master.
Thank you for choosing us to learn about the Agile Scrum Framework.