Writing Acceptance Criteria can be a difficulty process, but is it an important aspect of writing the perfect User Story? You read this because:-.

• As a team member you have been charged with writing a User Story and do not understand where to start.
• You have actually written some User Stories prior to and the reception was less than frustrating.
• The team are looking to compose User Stories that are great, but they require numerous revisions and are not actually “Agile” due to the fact that they take too long and the Team gets impatient.

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 is subject to change – the Customer remembers something they forgot to discuss to you, the Story is more Complex than one User Story, the list goes on. Nevertheless, it is possible to write a really, really good User Story if you follow the tips below.

We have assumed that you understand the standard terms and Artefacts that are used in Agile Product Development. We also know that there are lots of “tweaks” and flavours of Agile (such as Lean and Kanban). What we explain below should fit into any environment and architecture.

Writing Acceptance Criteria: The User Story Analysed.

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

As the (User) I wish to (perform an activity) so that (preferred outcome).

For example:-.

As a Passenger I wish 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, the outcome is the most vital factor,even outweighing the User’s voice. This is since the success of your User Story and the Code supporting it will be based on how closely it Delivers what was expected. Many User Stories are questionable on outcomes, and this will certainly affect the Quality, develop tensions when it comes to Acceptance and delay the Scrum Project as a whole.

Writing Acceptance Criteria: Where to Start.

You already have a general Narrative that underpins your Story. The total principle is understood, it has been drafted out in Epic Stories and themes, and you have been assigned several of the User Stories. There have already been workshops arranged by the Product Owner including Stakeholders as Users, and you most likely were included in those workshops. So you may already know (or think you understand) your User.

Writing Acceptance Criteria: Determining your User(s).

Your Product Owner (the Voice of the Customer) must be the expert on who does what in business, and would be your first call for whose Story you will be composing. You likewise may have met Users in workshops. However, do not assume that you have identified all the Stakeholders. Set up a meeting with the Stakeholders you understand and verify that you have the best person. For example, the financial Manager understands that new accounts need to be credit-checked, the credit Management agent does the real processing. While you are not delving into the detail, the agent experiences the pain points, not the Manager.

Often you do not have the luxury of the physical User and you will have to develop a “Persona”. We discuss this elsewhere, however you need to make this Persona as genuine and vital as possible to get the best results.

Does the Activity Add Value?

This should already have been specified and figured out in earlier workshops before the User Story was identified. However, you may find that the activity is redundant or duplicated. This can take place in Companies where the process design is less than perfect and individuals are working in silos. This is where User identification is Valuable – it can help to prevent rework. A case where this happened was at a bank, where the departments on the eastern and western side of a towns used totally different terminology to describe the same process. The developed value should be able to be tracked throughout each Sprint during the Daily Standup meetings.

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).

Users typically inform you what they want; it is your Job to discover what they Require. This will be the outcome of your User Story. Once you have specified and agreed the outcome with the User, you will make a note of the “Conditions of Satisfaction”. These are the outcomes that will define whether the User is happy with the Delivered Software. The conditions are redefined as Acceptance Criteria, and must all be satisfied before the Product is Accepted. You are not a scribe, you are an agitator. You do not want to Deliver the status quo, you wish to Deliver an improvement, no matter how small.

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

Writing Acceptance Criteria: Ask the Dumbest Questions.

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

Fly Above the Radar.

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

• The brain keeps in mind handwritten notes in a different way from typed information. The activity of placing sticky notes on a Chart or wall “Sticks” better in your memory.
• The act of writing out notes helps the Change Management Process. Writing something down Initiates Acceptance, especially if it is a new Concept.
• This is a Team Effort. A strategically placed User Story on an office wall, where more than one Stakeholder can view it encourages debate.

Initially User Stories were written on Index Cards. This still Works – they are big enough to write the basics, too little to explain, and simple to file and handle.

The Strength of Teams – the Workshop.

Teamwork is vital in getting a good User 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 a great hand), Storyboards are a great Tool for getting the concept out, there will constantly be Scrum Team members who have a strong Visual Sense.

Writing Acceptance Criteria: Get the Right Story.

These might seem like obvious Strategies and you are already following them. However if you are not Producing spectacular User Stories, maybe you ought to reassess your user story creation process. Try and avoid Stakeholders popping out of the woodwork. This should be the Role of the Product Owner, but there are always surprises out there. Distinguishing desires from needs is very intuitive – do not think this is something that can be taught – the dumb question is very valuable in this regard. If you constantly use these Principles to your User Story as well as follow what we have said here, you will start receiving accolades and recognition! The processes for generating the user stories can be reviewed as part of the Sprint Retrospective Meeting.