Getting well written

requirements and user stories

from your Business Analysts
(Agile’s unsung heroes!)

Keith Richards
www.agileKRC.com
Presentation Structure
• Introductions
• The basics about agile and requirements
• The harsh reality about requirements
• 7 top tips for writing good requirements
• A classic user story!
• Training and certifications
• Further information / Next steps
• Close and questions.
Introductions
• agileKRC is a pioneering training and consultancy company
• Specialising in all things Agile
• Focusing on improving Agile capability at scale
• Keith Richards
o 15 years experience in agile methods
o Wide range of Business Analysis experience
o Author of ‘Agile Project Management’ (TSO)
o Voted ‘Most Valuable Agile Player’ UK Agile Awards 2011.
Agile and requirements – the basics
• Agile is new way of thinking:
✓ iterative, incremental, managing scope
• Agile has highlighted several new techniques:
✓ burndown charts, estimation games, user stories
• Agile needs certain conditions:
✓ collaboration, prioritisation, business engagement.
The User Story - have we struck gold?
As a <role> I want to <action> so that <benefit>

• Is that it?
• Is it all down hill from here?

Unfortunately the answer is no. We have a good technique and a good

structure. The secret is all about what you put into the user story.
Sausages and GIGO
• GIGO stands for ‘Garbage in, Garbage out’
• User Stories work in the same way as a sausage machine
• The sausages are as good as the ingredients that you put in.
Getting real – what really happens?
What do you get when you ask for people’s requirements?

• I want the project completed for less than 200K

• I want it user friendly
• I want it fast and reliable
• I want to email the customer when their DVD is dispatched
• I want to update a person’s contact details.
How do we get good requirements and user stories?
• Stick with best practice but remember that best practice is
always evolving
• A lot of traditional thinking still works
• User stories have ‘raised the bar’
• The need to excel in this area is now vital
Tip No. 1: Keep saying why!
• Is being a BA the easiest job in the world?
• A three year old kid could do it perhaps?
• ...only kidding – it is a skill that takes time to learn
• Get to the REAL requirement not just the first impression.
Tip No. 2: Build on the User Story structure
• Feel free to adapt it
• Include acceptance criteria
• This makes a big difference
• Check out INVEST – it’s OK but not brilliant!
o independent
o negotiable
o valuable
o estimable
o small
o testable.
Tip No. 3: Go for purity; avoid the solution
• It is relatively easy to build the solution
• The hard part is knowing what the problem is
• Remove anything that looks like a solution
• Don’t be lazy, no matter how tempting it may be
• You will be amazed how
useful a comments column is.
Tip No. 4: Interact!
• A user story is defined as a ‘token for a conversation’
• That conversation needs to happen
• Assess the ‘golden ratio’
o how much time is spent writing the user story?
o how much time is spent discussing the user story
o the ratio should be 10:90.
Tip No. 5: Start with the end in mind
• Scope creep is very rarely scope creep!
• User stories do not exist in a vacuum
• What is the primary goal?
• What are we trying to achieve?
• Everything maps onto this
• MoSCoW fits in well here.
Tip No. 6: Beware the role of the Product Owner!
• Potentially this can be disastrous
• A lot of agile focuses on the PO
• But how far can a PO go?
• Our advice is to create a partnership
• The BA and the PO bring different
things to the party.
Tip No. 7: Move centre stage; become pivotal
• The BA is not a ‘walk on’ part
• Stop the techies getting carried away
• Get under the skin of the business
• Add value – hence the word ‘analyst’
• A bit like copywriting perhaps?
My favourite ever User Story
• As a club manager
• I want to manage my club
• So that my club is managed effectively

Just remember to think ‘sausages’.

Training options
• Business Analysis Practice (3 day course)
• Requirements Engineering (3 day course)
• Core modules towards the BCS Diploma in Business Analysis
• Regular public courses in London, Leeds and Cardiff.
In summary

Don’t forget about the sausages!

Further Information / Next Steps
• agileKRC offers accredited agile courses, in-house
training and coaching.
• Would you like an agile assessment or a project health
check?
• Email us at info@agileKRC.com to find out how we can
help you on your agile journey.
 Getting well written
requirements and user
stories
Thank you!
info@agilekrc.com
www.agileKRC.com
 Consulting
Training
Coaching
Making agile work for you Recruitment

User story checklist

This checklist is for use on a ‘mature’ user story, i.e. a user story that has undergone discussion and
iteration.

Format
A user story is written by a business analyst in this format (standard elements shown in CAPITALS):

As a ROLE I want a FEATURE so that I get a BENEFIT.

The user story is checked against ACCEPTANCE CRITERIA to determine whether it is DONE.

Big three questions

1. Immediately after reading the user story is it obvious what the user story is about?
2. Does each element of the user story add significant value and avoid duplication or partial
duplication of other elements?
3. Is it 100% free of ‘the how’ (i.e. the solution)?

Top ten questions

1. Are there less than 6 questions making up the acceptance criteria?
2. Is the ROLE specific and does everyone on the project know what that role does?
3. Is the user story less than 26 words and is the acceptance criteria less than 51 words?
4. Is there an area on the user story for making important notes that may not be covered by
the normal standard elements?
5. Do the elements of the user story clearly correspond to a WHO, a WHAT and a WHY?
6. Is the user story annotated to clearly show whether it is small (for working on) or large (in
need of further decomposition, a.k.a. an Epic)?
7. Are all acceptance criteria written without any form of pseudo-code (e.g. can I book a course
in the next financial year, as opposed to, if course-date > this-fin-year AND < this-fin-year+2)?
8. Has the user story reached ‘its final state of why’? i.e. has the question why? been asked
enough times that we now have the real requirement and not a symptom or intermediate
requirement.

...and finally, just to be on the safe side…

9. The WHO isn’t ‘user’ is it?
10. Make sure that there is nothing in the user story that goes anything like ‘as a stock controller
I want to control the stock so that the stock is controlled’?

Phone: 44 (0)207 039 3679

Email: info@agileKRC.com