A deep dive into components of a user story, looking at beyond the basics that we all know (ought to know) and are familiar with. The deck provides guidance on developing individual components that make up a ‘Ready for Dev’ user story.

1. @Kubairwww.shirazee.com
User Stories – Beyond Basics

2. @Kubairwww.shirazee.com
User Stories – more than an introduction
This deck takes a deep dive into components
of a user story and provides guidance on
developing individual components that make
up a ‘Ready for Dev’ user story.
You will not need to define all the
components detailed here for all your
User Stories – use the common sense
principle to determine the level of detail
you drill down to for each User Story’s
completeness

3. @Kubairwww.shirazee.com
User Stories – the JEDI principle
User Stories represent the ‘Just Enough
Documented Information’ (JEDi) required for a cross
functional agile team to understand, analyse, size,
estimate, design, develop and test an independent
piece of functionality that holds value for the
user(s).
Simplicity, independence,
completeness and user value
make for a good user story

4. @Kubairwww.shirazee.com
User Stories – the C-Gaffsal principle
Completenes
s
Is complete at that point in time and open to
negotiation and refinements
Goal Is to start a conversation with a real user
Altitude Can vary (Mountain summit to grain of sand) i.e. Epic
to task
Format A single sentence
Flexibility Is flexible to adaptation.
Scope Is to create JEDI for a single activity/function
Add-ons Feel free to scribble wireframe components to add
visuals to the story
Language Simple comprehensible

5. @Kubairwww.shirazee.com
User Story – a refresher…le’format
As a < role >
I want < activity >
so that < business value >
Role - represents who is performing the action. It should be a single
person, not a department.
Activity – represents the action to be performed.
Business Value – represents the value to the business. Why is this
story important?
If you are struggling to find the business
value of a User Story question its purpose!
It may be a task that sits within a Story!

6. @Kubairwww.shirazee.com
User Story – beyond basics
As a < role >
I want < activity >
so that < business value >
Role - represents who is performing the action. It should be a single person, not
a department.
Activity – represents the action to be performed.
Business Value – represents the value to the business. Why is this story
important?

7. @Kubairwww.shirazee.com
User Stories – additional components
Acceptance Criteria
(AC)
Technical
Description
Decomposition:
into tasks and sub-tasks
(BE + FE Dev + QA)
Size
(Story points / T-shirt sizing / Relative
Mass Valuation)
Test Cases
Dependencies:
r e l a t e d & / o r
dependent USs,
PoCs, Blockers
Dependencies:Frontend:
Design&/orTheme
UserStory:Description
(US)
Asa<role>
Iwant<activity>
sothat<businessvalue>
Exception Criteria
(EC)
TaskHours
Estimate(Hrs)
Events - Sign-off from Product owner Team Consensus
Recalibrate Processes and Techniques
Definition of Done (Checklist)
Covering These plus agreed standards
That’s a Ready for Dev User Story

8. @Kubairwww.shirazee.com
Specifies who does what and
gains what value from the
activity: the US should be:
+ Meaningful
+ Right sized for the planning
stage that we are at.
E n v i r o n m e n t ( H W ) ,
required Subs, PoCs, risks
and talent required -
a n y t h i n g t h a t c a n
potentially be a blocker /
impediment
W h a t a s y s t e m
should not do is as
important as what it
should do.
The direction / options and/
o r P o C s / r e s e a r c h
r e q u i r e d - n o t a
decomposition exercise
Recalibrate based on retrospective insights
from past sprints.
For example pull up 5 to 7 user stories across
the size spectrum (Xs to XL / 1 SP to 8 SP)
delivered, analyse variance between task
hours estimates and actual task hours
estimates and where a differential exists
discuss why, the insight gained must be used
in future sizing and estimations to improve the
accuracy of the team’s sizing and estimation
judgement.
User Stories – additional components contd.

9. @Kubairwww.shirazee.com
AC must be written by the
Product Owner &/or
Client side Business
analyst.
Where this creates a
b o t t l e n e c k o r i s
challenging - facilitate the
process, including writing
likely ACs for the story.
Automate testing from the earliest
sprint possible
1) automated unit tests
2) automated feature verification tests
3) automated functional/regression
tests 4) manual testing.
All testing tickets on JIRA must
facilitate the client side UAT process.
For items deeper in the backlog,
give a rough estimate. By the
time the team actually begins to
work on those items, the
requirements may change -
don’t go waterfall on sizing and
estimates.
Decomposed tasks
and sub-tasks feed
this process; it is a
collaborative team
exercise to build
c o n s e n s u s ,
o w n e r s h i p a n d
commitment.
Don’t forget the dependencies on
Front end Design and Theme layer -
analyse the UX and UI requirements
early on and build the timelines for
their delivery & implementation in
your sprint plans
User Stories – additional components contd.

10. @Kubairwww.shirazee.com
Hint!
Setup a Skype UAT Group
lead by the QA lead to walk
the client side UAT lead
through the process
Hint!
Start with Epics and work
your way down the detail
whilst grooming the Product
Backlog
Hint!
Compare Estimates against
baselined user stories in the
PS User Story Library - its a
good measure of team
confidence.
Hint!
Establish an upper limit
- e.g. no task is >16
team hours
User Stories – additional components contd.

11. @Kubairwww.shirazee.com
Thank you.
If you got value from what I have shared please consider
giving back by contributing to @BringPTP, you can follow,
broadcast or donate: http://gofundme.com/bringptp
Peace Through Prosperity (PTP) improves the local/domestic environment
for peace by nurturing prosperity. PTP alleviates poverty through
empowering micro-entrepreneurs with knowledge, skills, ability and
increasing their access to income and opportunities. PTP supports small
businesses, owned/managed by vulnerable and marginalized
individuals/groups in society.
PTP is innovating program design and delivery by using Agile design and
delivery frameworks to create and deliver low cost, immediate and lasting
impact programs in ‘at risk’ communities. www.bringptp.com