The document presents a 10 step model for agile requirements that includes defining the objective, stakeholders, vision, roles, personas, user stories, acceptance tests, development, delivery, and checking the delivered value. It argues that there is more to requirements than just user stories and that projects should either take a "salami slice" or goal-directed agile approach. The model is intended to provide insights and ideas for linking together all aspects of agile requirements.

1. The 10 Step Model for
Agile Requirements
ACCU Conference 2011 allan kelly
http://www.allankelly.net
Oxford
Twitter: allankellynet
Software Strategy Ltd.
http://www.softwarestrategy.co.uk

2. Allan Kelly
• Training & Coaching for Agile
adoption and deepening
• Author:
• Changing Software Development:
Learning to be Agile, Wiley 2008.
33 Business Strategy
97 Things Every Programmer Patterns for Software
Should Know, Henney, 2010 Creators
Context Encapsulation in Pattern
Languages of Program Design
volume 5, 2006
www.softwarestrategy.co.uk 2

3. How do you do requirements in Agile?
Gee, I thought
everyone knew
that….
Actually, there’s
User more to it than
that…
Stories!
www.softwarestrategy.co.uk 3

4. And what about
Stakeholders and User Stories
CUSTOMERS ?
Where’s the
Aren’t personas in
Business value?
here somewhere?
Where do roles
come from?
What are reasonable
actions and reasons?
As a <Role>
I can <Action>
So That <Reason>
www.softwarestrategy.co.uk 44

5. There is more to Requirements then User Stories
www.softwarestrategy.co.uk 5

6. In the beginning….
There is work to do
www.softwarestrategy.co.uk 6

7. Work needs
doing
Product Project
New thing
(Maintenance)
Start & end
Enhancements to dates
something that exists New team
Team exists Goal
Thing exists driven
Salami slice
www.softwarestrategy.co.uk 7 7

8. Salami Agile
Interface Agile team to
traditional organization
• Limited Agile
• Limit change risk 1. Big up front requirements,
• Limited benefits design, estimation, etc.
2. Iterations
Comfort food… • Slice off requirement
appearance of
normality; • Implement (Deliverable)
can roll with • Repeat
changes…
But more work
www.softwarestrategy.co.uk 8

9. Goal directed projects
• Business case sets out objective
• Not a shopping list of features
• How goal is achieved is part of the
Increase online
work sales by 10%
• Research, experimentation
• Governance based on
• Progress against goal
• And future potential
Reduce customer churn by
5% [by improving CRM
system]
www.softwarestrategy.co.uk 9 9

10. Goal directed: Start with Output
• Only outputs have value
• Decide what you are trying to achieve
• Find inputs to create outputs
Work back - Find inputs
needed to reach goal
Inputs Inputs build
www.softwarestrategy.co.uk 10 10

11. Take your pick… Project
Goal
Directed
Salami
Agile Agile
www.softwarestrategy.co.uk 11

12. Agile 10 step
1. Objective
2. Stakeholders
3. Vision
4. Roles
5. Personas
6. User Stories
7. Acceptance Tests
8. Development
9. Delivery
10. Value check
www.softwarestrategy.co.uk 12 12

13. Stakeholders
From above: What is the goal?
10 Step Why are we doing this?
Who are the stakeholders?
1. Objective What is success to them?
2. Stakeholders
Team’s Vision for the solution
3. Vision
Roles
4. Roles Who will use the system?
5. Personas
Key Personas
6. User Stories
Personas
7. Acceptance Tests How do we know we
8. Development are done?
9. Delivery Close the loop:
10. Value check • Progress against objective
• Value delivered? Who are the
• Should we continue? customers?
How are they
www.softwarestrategy.co.uk segmented? 13

14. Put a man on the
Objective – why? moon and return
him safely…
I have a dream…
Is NOT… Could be…
• Requirements document • Mission statement
• Shopping list • Marketing brief
• Technical • Market opportunity
assessment
Beat Xerox • Project Initiation
Cannon
Document
Encircle Caterpillar
Komatsu
www.softwarestrategy.co.uk

15. Objective
• A reason to start • A reason to stop
• Start thinking • Measure of success
• Gather resources • How do you know
you are done?
• Measure progress
against objective
www.softwarestrategy.co.uk

16. Stakeholders
Stakeholder: Any person or
organizational group with an
interest in, or ability to affect,
the system or its environment
Stakeholder: Human or other
legal entity (company etc.)
Gilb, Competitive Engineering, playing a system role and
2005 thereby having a valid interest in
the development of the system
or product. Subclasses include:
beneficiaries; operator;
Alexander & Beus-Dukic,
regulator; negative stakeholder.
Discovering Requirements, 2009
www.softwarestrategy.co.uk 16 16

17. Stakeholders
The process of working effectively
with stakeholders has three major
steps:
• Stakeholder identification
• Stakeholder analysts
• Stakeholder management
Candle, Paul & Turner, Business
Analysis Techniques, 2010
www.softwarestrategy.co.uk 17 17

18. Stakeholders & Stakeholders
Stakeholders
Internal External
Stakeholders Stakeholders
Regulators,
Customers
etc….
www.softwarestrategy.co.uk 18

19. Stakeholders have goals too
Might be aligned with your project
• Or might be a little different
oal
lde rA
keho
Sta
roje ct g
P
er C
Stakehold
www.softwarestrategy.co.uk 19 19

20. All customers are not
equal… segment!
www.softwarestrategy.co.uk 20

21. Vision
• How are you going to meet the
objective?
• The answer to the stakeholders needs
• Something you can build
www.softwarestrategy.co.uk 21

22. Stakeholders
• The work can deliver benefits to many
stakeholder
• Some stakeholders are interested
even if the work has no direct value to
them
Roles
• Only some of the stakeholders will
interact directly with the system
• All roles are stakeholders but not all
stakeholders have roles
Personas
• Add depth of understanding about
roles
• Different personas to the fore at
different times (iterations/releases)
www.softwarestrategy.co.uk 22 22

23. The middle bit…
• Acceptance test
• Development
• Product Backlog
• Sprints Not today, thank you
• …
• Delivery
www.softwarestrategy.co.uk

24. Value – did we make a difference?
• Delivery technology “fix”
• But fixes wrong problem
• Fix technology but not the process
• Deliver great software
• But nobody uses it
• Deliver what was asked for
• Not what was needed
• Doesn’t get used to the full
Delivery is only the start…..
www.softwarestrategy.co.uk 24

25. Mind the Gap
• Value delivered not the same as value
recognized
• Software delivered may never be used: $0 value
Or
• More useful then expected: +$$$ value
www.softwarestrategy.co.uk 25

26. Question time
• Do you…
• Adequately identify and quantify the
benefits of IT projects?
• Overstate benefits in order to obtain
funding?
• Adequately review and evaluate
completed projects?
www.softwarestrategy.co.uk 26

27. The truth about project evaluation
• 70% believe they are failing to identify and quantify
the benefits adequately
• 38% openly admit they overstate the benefits in
order to obtain funding
• 80% report that the review and evaluation of
completed projects is also inadequate
• due to the focus on whether the project achieved cost, time
and quality objectives and not on whether the intended
benefits were realized.
Survey of 100 IT/IS & Delivering value from IS and IT investments, John Ward,
Cranfield School of Management, 2006
Business managers in
http://www.som.cranfield.ac.uk/som/dinamic-content/
UK and Benelux, 2006 research/documents/deliveringvaluereport.pdf
www.softwarestrategy.co.uk 27 27

28. Stakeholders define value
• Benefit is value delivered to stakeholders
• So, you need to know who the stakeholders are to determine
value
• How do you measure benefit?
• Ask the stakeholders!
www.softwarestrategy.co.uk 28 28

29. Business Practices that Enhance
Productivity
Getting the most from IT requires:
1. Move from analogue to digital processes
2. Open information access
3. Empower the employees
4. Use performance-based incentives
5. Invest in corporate culture
6. Recruit the right people
7. Invest in human capital
Source: Wired for
Innovation,
Brynjolfsson & Saunders,
2010
www.softwarestrategy.co.uk 29 29

30. Another view
www.softwarestrategy.co.uk 30

31. Agile 10 step
• A process?
• Maybe
• A check list?
• Maybe
• Link it all together?
• Hopefully!
• What do you think?
• Give you insights?
• Give you ideas?
www.softwarestrategy.co.uk 31 31

32. Summary
• More to requirements than User
Stories
• Choose
• Salami Agile or,
• Goal Directed
• Agile 10 Step
Thank you!
• Evaluate! Allan Kelly – allan@allankelly.net
http://www.allankelly.net
http://www.softwarestrategy.co.uk
http://blog.allankelly.net
Twitter: allankellynet
www.softwarestrategy.co.uk 32