When defining Epics and User Stories, the first question we need to answer is ‘What the User Really Wants?’

“You Can’t Always Get What You Want, If You Try Sometime, You Can Get What You Need”
Mick Jagger and the Rolling Stones

There is an art to composing a User Story and it starts long before the Sprint Planning Meeting. It is very easy to write a User Story based on what your User wants. Where the skill comes in is Defining what the User needs, just as Mick Jagger sang. This is why much of the literature on User Stories mentions the Product Owner as the crafter of Epics. They are often the crafter of the User Stories as well. There are several reasons for this:-

• The Product Owner has usually Worked for the Company for a number of years and understands the Stakeholders.
• The Stakeholders know the Product Owner, which makes it easier for them to collect the information needed for User Stories.
• A Product Owner can recognize specific staff members who have the required knowledge to add to a User Story.
• The Product Owner knows how the Company Works and the Organizational Culture, as well as the Policies, Processes and Procedures.

Crafting User Stories and Epics.

Just because the Product Owner is involved in writing the Epics and User stories does not mean the remainder of the Team are not involved. They provide assistance to the Product Owner. When crafting Epics, it is best that the Scrum Product Owner is accountable for getting them Done. They can then Communicate the Epics to the Stakeholders and Team members. User Stories originate from breaking down an Epic. The Epic is broken down into its most granular form. The user Story usually explains a single activity within that Epic. With the overview provided by the Epic, any Team member should be able to get the information required to compile a User Story. They can do this in Collaboration with one or more Users who the Product Owner has identified. There are a few ways of getting the information Required, and the Team member is not limited to Face-to-Face Interviews.

Tools and Techniques.

Epics: Interviews.

It is a strange characteristic of Human Nature and our desire to be social beings that, when asked a direct concern, we will frequently reply with a response that we think the questioner desires to hear, instead of our own Opinion or View. This is among the most significant Risks in gathering information, and if you are Interviewing somebody, you need to also be careful not to Frame Your Questions in such a method that you get the response you were searching for. A Valuable strategy for inviting the Interviewee to put forward his own viewpoint is making use of Open-Ended Questions.

Interview Questions

An Open-Ended Question can not be addressed with a “yes” or “no”. It must be worded in such a way that we show compassion to the Interviewee. We Value their input and knowledge and do not try to enforce our opinions, but stay neutral.

• Open the Interview with a brief explanation as to what the function of the Interview is and how you believe that your Interviewee can provide Valuable information. You ought to make it clear that they are the professional and you know little about their area of proficiency.
• Start with a broad concern about the Day-to-Day Processes and Activities that the User is associated with, for example their day as a call-centre operative. If you are writing a User Story, it will have to do with only one of the activities, but this sets the context.
• Pick a prominent point and ask specific questions, such as what actions they undertake to start their day and log in to the system. This might be your User Story.
• Ask how they would improve the present method of operation (how it could be).
• Summarise what you have Learnt (your User Story) and make sure that the User agrees with the detail.
• Ask what would be proof that the User Story has been Developed properly (simply put, what are the Acceptance Criteria?).
• Thank your Interviewee and end the Meeting.

Epics: Workshops.

A Workshop is a great way of getting a variety of input and viewpoints. Beware to select attendees carefully; often staff members will not be as open when their Manager is in the Meeting, depending on the Management style. Healthy debate ought to uncover issues and Pain Points that might be ignored in a One-on-One Interview. The Workshop is likewise a terrific Change agent for keeping Users involved with the Project, which aligns with the Values and Principles of the Agile Manifesto.

Epics: Observation or Work study.

There must be very few Companies that do not have their Business Processes Mapped. It can be rewarding to compare the Mapped Processes with how people really Operate – you will often get differences between what should take place and what does occur. This can also occur where you have a big User Group (like a call centre), where you can only Interview one or a few of the Users. You can also discover differences where there are numerous branches – try to check out 2 or more branches for comparison. You can likewise use Questionnaires to collect information from all the branches, which is a lot quicker and cheaper than visiting them.

We found these books great for finding out more information on Agile Scrum:

Epics: Questionnaires.

Questionnaires are a useful way of collecting extensive information from a large group of Users. Redistribute the collected information, either for discussion in a Meeting or via a Round Robin Process using email.

If you Plan on using Questionnaires, it is best to utilize them for an Epic or numerous Features or User Stories, so that you gather the maximum amount of details with the minimum of disturbance to the Users’ Workday.

Evidence of Concept.

User Stories need to be Critiqued and Tested. This can be Done by the Scrum Team (Agile Scrum Master, Scrum Product Owner, and Scrum Development Team) in Workshops. The objective would be to:-.

• Test whether the User Story makes good sense by itself.
• Assure that the Acceptance Criteria are Measurable and will satisfy the Users expectations.
• Validate that the User Story lines up with the other User Stories making up the Epic or Feature.
• Commit to the Stories in preparation for the next Sprint.

Composing User Stories is an art, and gets much easier with experience. Instinct is Required to identify whether your Customer has told you what they require and not what they desire. You do not want to reproduce the legacy Product. This can occur if you serve as a scribe when crafting the User Story, instead of using critical yet objective thinking to the information you have collected. The customer interactions do not end with the definition of the Epics and User Stories, they are available to support the Scrum Team throughout the Sprint, through to the Sprint Review meeting.