TheFARM EducationAgile Requirements

BACKLOG

History Of Software Requirements

A Little On The Agile Process

Telling Stories - Agile Requirements

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.

Welcome to the 1970s!

Analyse

Design

Build

Test

Release

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.

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!)

OLD REQUIREMENTS

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.

AGILE MANIFESTO

We are uncovering better ways of developingsoftware 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 negotiationResponding to change over following a plan

That is, while there is value in the items onthe right, we value the items on the left more.

AGILE APPROACH

Using Agile We:

• Start with a set of Stories in a Backlog.

• Collaboratively prioritise and refine Stories for build.

• Work using defined periods of time (a Sprint).

• Extract Tasks from Stories to complete in a Sprint.

• Accept that requirements can and do change.

• Always have shippable software.

AGILE REQUIREMENTS (STORIES)

Story Detail and Size (Points).

user role

perform an action

achieve a benefit

AGILE REQUIREMENTS (STORIES)

Acceptance Criteria.

AGILE REQUIREMENTS (STORIES)

EPICWay Too Big… it’s an…

SCRUM BOARD

BURN DOWN

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

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