How can you Write Perfect User Stories and how can they lead to successful projects? Lets first consider the reason why you may be reading this article:-.

• You have been tasked with composing a User Story and don’t know where to start.
• It might be because you have actually written some User Stories before and the reception was less than overwhelming.
• You write User Stories that are great, but they need numerous revisions and are not actually “Agile” since they take too long and the Team gets impatient.

So you would like to write the perfect User Story, this time and every time. Well, we are sorry to disappoint you, there is no perfect User Story. The User Story is a living Document and undergoes change – the Customer keeps in mind something they forgot to discuss to you, the Story is more Complex than one User Story should be, the list goes on. However, it is possible to compose a really, truly great Story if you follow the pointers listed below.

We have assumed that you understand the standard terms and Artefacts that are utilized in an Agile Development Project. We also know that there are lots of “tweaks” and flavours of Agile (like Scrum, Lean and Kanban). What we describe listed below should suit any environment and architecture.

User Stories Analysed.

We start off the User Story by expressing it in this way:-.

As the (User) I desire to (carry out an activity) so that (preferred result).

For instance:-.

As a Passenger I want to call a cab so that I can get to my destination on time.

You might think the activity is the most important Component; after all that is what will be Coded. However, it is the outcome that is the crucial element, even surpassing the User’s voice. This is because the success of your User Story and the Code supporting it will be based on how carefully it Delivers what was anticipated. Many User Stories are sketchy on outcomes, and this will definitely affect the Quality, create tensions when it comes to Acceptance and delay the Project as a whole.

User Stories – Where to Start?

You currently have a general Narrative that underpins your Story. The overall idea is understood, it has actually been drafted out in Epic Stories and themes, and you have been assigned one or more of the User Stories. There have already been workshops organised by the Product Owner involving Stakeholders and Users, and you most likely were included in those workshops. So you may already understand (or think you understand) your User.

Recognizing your User(s).

Your Product Owner ought to be the guru on who does what in the business, and would be your first call for the Story you will be writing. You likewise may have met Users in workshops. However, do not assume that you have identified all the Stakeholders. Establish a meeting with the Stakeholders you know and verify that you have the right person. The financial Manager knows that new accounts must be credit-checked, the credit Management representative does the real processing. While you are not delving into too much detail, the agent experiences the pain points, not the Manager.

In some cases you do not have the luxury of a genuine live User and you will need to develop a “Persona”. This Persona should be as real as possible to get the best results.

User Stories: Does the Activity Add Value?

This should already have been defined and identified in earlier workshops prior to the User Story being identified. You might discover that the activity is redundant or duplicated. This can occur in Companies where the process model is less than perfect and individuals are working in silos. This is where User identification is Valuable – it can avoid rework.

What is the User’s Goal – the Outcome?

” You Can’t Always Get What You Want, But If You Try Sometimes, You Might Find, You Get What You Need” (Rolling Stones).

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

Users generally inform you of what they want; it is your Job to find out what they Require. This will be the outcome of your User Story. As soon as you have actually defined and agreed the result with the User, you will write down the “Conditions of Satisfaction”. These are the outcomes that will define whether the User is happy with the Delivered Product. The conditions are redefined as Acceptance Criteria, and need to all be satisfied before the Product is Accepted. You are not a scribe, you are an agitator. You do not wish to Deliver the status quo, you want to Deliver an improvement, no matter how small.

Ask the Dumbest Questions.

Never assume. Question any term used, even if you think you know what it means, it might have a different context here. If another department or Customer is mentioned, visit that department or Customer. If a Document is mentioned, ask for a copy. You are not going to write everything down, but glossing over anything may cause problems later on.

User Stories: Tools and Techniques.

Keep the Story Visible at all times. We Recommend that you stick to paper and pen, Whiteboards and Wall Charts to get the current information out there. There are 3 factors for this:-.

• The brain remembers handwritten notes in a different way from typed information. The activity of putting sticky notes on a Chart or wall “Sticks” much better in your memory.
• The act of writing out notes assists the Change Management Process. Writing something down Initiates Acceptance, particularly if it is a new Concept.
• This is a Team Effort. A strategically positioned User Story on a workplace wall, where more than one Stakeholder can see it encourages debate.

Initially User Stories were composed on Index Cards. This still Works – they are big enough to write the essentials, too little to go into detail, and easy to file and handle.

The Strength of Teams – the Workshop.

Team effort is vital in getting a good Story out there. The best way of doing this is to hold Workshops where Users and Developers get together and expand the User Story on the walls of the Meeting room. If you have a Well-Developed right brain (and an excellent hand), Storyboards are an excellent Tool for getting an idea out, there will always be Scrum Team members (Scrum Master, Product Owner and Development Team) who have a strong Visual Sense.

Get the Right Story out there.

These may seem like obvious Strategies and you are already following them. If you are not Producing spectacular User Stories, possibly you ought to reassess what is happening. Attempt and avoid Stakeholders popping out of the woodwork – this should be the Role of the Product Owner, however there are always surprises out there. Distinguishing desires from requirements is really intuitive – do not believe this is something that can be taught – the dumb question is really helpful in this regard. A great exponent of XP (Extreme Programming), Bill Wake came up in 2003 with an acronym you can apply: – “INVEST”. It still Works. If you always apply these Principles to your User Story as well as follow what we have said here, you will start receiving accolades and recognition!