A quick summary of our approach to software & website development. We follow the Agile Manifesto which means we place value on individuals & interactions (over processes & tools), working software (over comprehensive documentation), customer collaboration (over contract negotiations) and responding to change (over following a plan).

1. Agile Requirements
Education Series

2. BACKLOG
History Of Software Requirements
A Little On The Agile Process
Telling Stories - Agile Requirements

3. THE JOURNEY - WATERFALL
Original software development was mostly a
“hack away until it works” effort.
Waterfall was born of the desire to better manage complex
projects.
Analyse
Design
Build
Test
Release
Welcome to the 1970s!

4. SLIPPERY RESULTS
Software project failure* exceptionally high at 61%.
The main reasons for failure include:
• Incomplete or Changing Requirements
• Lack of User Involvement or Bad Communication
• Delivered Late or Over Budget.

5. OLD REQUIREMENTS
Using Waterfall We Try To:
• Capture Detail About Requirements All At Once Before We
Start.
• Often Performed Independently of Eventual Delivery Team.
• Estimate Project Effort and Cost Off Requirements.
• Restrict Change by Penalising For It (and we still fail!)

6. OLD REQUIREMENTS

7. A NEW WAY
During the 1980s and 1990s approaches changed.
The goal: to fix what was wrong with IT project delivery.
The result: lots of new great ways to do project delivery.
The problem: which one to use?!
In 2001 a group came together in Utah and bought many
disciplines together and produced the Agile Manifesto.

8. AGILE MANIFESTO
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.

9. AGILE APPROACH
Using Agile We:
• Start with a set of Stories in a Backlog.
• Collaboratively prioritise and refine Stories for build.
• Accept that requirements can and do change.
• Work using defined periods of time (a Sprint).
• Extract Tasks from Stories to complete in a Sprint.
• Always have shippable software.

10. AGILE REQUIREMENTS (STORIES)
Story Detail and Size (Points).

11. AGILE REQUIREMENTS (STORIES)
Story Detail and Size (Points).
Front of card Points = effort required

12. AGILE REQUIREMENTS (STORIES)
Acceptance Criteria.
Back of card

13. AGILE REQUIREMENTS (STORIES)
Way Too Big…

14. AGILE REQUIREMENTS (STORIES)
…we call it an

15. SCRUM BOARD
Where we track all the stories

16. BURN DOWN
Work is broken down into a forecasted number of sprints & all
sprints are completed within a pre-determined timeframe (e.g. 2
weeks). Stories are allocated to each sprint in order of priority &
progress is mapped on a burn down.

17. Are we Done?
(that’s a Scrum joke)

18. References
(1) REVIEW OF TRADITIONAL PROJECT FAILURE RATES
http://www.it-cortex.com/Stat_Failure_Rate.htm
(2) AGILE REQUIREMENTS BASICS
http://www.mountaingoatsoftware.com/topics/user-stories
Contact:
TheFARM Digital
+612 9690 1415
@thefarmdigital
http://www.facebook.com/thefarmdigital
http://www.thefarmdigital.com.au