Non-Functional Requirements:
Do user stories really help?
Rachel Davies
rachel@agilexp.com

My background
Past jobs:
Software Engineer, Sys Admin,
Systems Designer, Development
ManagerCurrent jobs:• Agile Coach, Agile Alliance Director,
Book Author, Conference Organizer

Who’s Here?
• Raise your hand if …
• new to agile?
• used agile?

HOW not WHAT
Photo from Andrew Stellman’s blog

Lots of terms

Requirements in Disguise

Agile Manifesto
Shared values
and principles
for betterways to develop
software(2001)
www.agilemanifesto.org

Agile Values
Individuals & Interactions over Processes & Tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan
While there is value in the items on
the right,
we value the items on the left more.

Agile Manifesto Principles (1)• Our highest priority is to satisfy the Customer
through early and continuous deliveryof valuable software• Welcome changing requirements, even late indevelopment. Agile processes harness change forthe customer's competitive advantage.
• Deliver working software frequently, from acouple of weeks to a couple of months, with apreference to the shorter timescale.
• Business people and developers must work
together daily throughout the project.

Agile Manifesto Principles (2)• Build projects around motivated individuals.
Give them the environment and support they need,and trust them to get the job done
• The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
• Working software is the primary measure ofprogress• Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Agile Manifesto Principles (3)• Continuous attention to technical excellence
and good design enhances agility The most efficientand effective method of conveying information toand within a development team is face-to-faceconversation.
• Simplicity--the art of maximizing the amountof work not done--is essential.
• The best architectures, requirements, and designs
emerge from self-organizing teams• At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordinglyAgile Lifecycle

How does an Agile teamremember them?

Is there a new Agilepractice?

Whole Team

Business people and developers must work together
daily throughout the project.

Talk about the lifetime ofthe softwareYAGNI
Mantra from XP - “You aren’t gonna need it”-- Ron Jeffries• Developing for future NFRs slows us down!
Keep options open
• Now vs Later trade-off• When is “Last Responsible Moment”?
• Educate the customer about the choice
being made• Can use Risk impact to prioritize NFR work.

The Customer / Product Owner• Don’t rely on theCustomer to tell youabout non-functional
requirements!
• Include technicalstakeholders inprioritization meetings.
• Make sure you havepeople with ops
experience in planningmeetings

The Team• Agile relies on crossfunctional teams withrelevant skills todeliver/maintain• Include sys admin
experience on team• Share the knowledge(by pairing)User Stories• User stories explain what the softwareneeds to do from a user perspective.
• Knowing who the user is and what
problems they are trying to solve helps us
develop better software.

Three Cs to a user story
Card: user goal written on an index card
Conversation: team gets to ask questions
Confirmation: acceptance criteria
Ron Jeffries, Xprogramming.com

Planning with User Stories

The cards aren’t mini-requirements specs!

Card format?

http://thesherpaproject.com

Can describe NFRs like this but is it worth it?

BBC Example story cards
As an operations engineer, I
want to be able toreconfigure the timeout of a
specific service request
without needing to restart thebackend service process
Examples from
Kerry Jones, BBC
Notice they are not"As a system”!

As an operations engineer,
I want to know howmany people are
currently watching
Eastenders on iPlayer

Titles + Tests
Keep it simple:• Story Title on the front of the card
• Acceptance Criteria on the back of thecard• NFRs are listed as Acceptance Criteria

Definition of Done
Agree a “Definition of Done” with teamMay need per story checks
Also per release checks - especially if somekinds of testing is expensiveClass of Service
Clean code not acustomer choice
Agree quotas ofdifferent types ofwork like a “qualitytax”
Use different colorcards
Eg, Yellow cards foroperational stuff, Bluefor technical debt/
spikes

Questions?

Thanks to:• Simon Baker• Jason Gorman• Kerry Jones• Duncan McGregor• Ivan Moore• Dave Nicolette• Duncan Pierce• Gus PowerFor sharing their experiences.

!
seiv
aDl
Racheo m!
c.
px
el
ig
rachel@ao m!
c.
px
elig
www.a

Agile Infrastructure
Team takes
responsibility forwork oninfrastructure andapply Agile
techniques• Visible• Testable• Automated, etc