Agile Development

Agile Planning
Content
Introduction to agile
Requirements gathering
Prioritisation and planning
Project documentation
Introduction to Agile
The Challenges
The ability to create and respond to change in order to profit in a turbulent
business environment.
Companies need to:
innovate better and faster
respond quickly to:
competitive initiatives
new technology
customer's requirements
What is Agile?
Set of methods and methodologies
Made up of a number of good practices
Help a team think and work more effectively
A mindset to improve team communication (effectiveness)
Only effective if the team's mindset shifts.
Benefits of Agile
Deliver on time and budget
Deliver a high quality product
Deliver maintainable code
Make the client happy
Work happy
Agile Practices
MacCormack identified four practices that lead to success:
An early release of the evolving product to the customer.
Getting rapid feedback from the customer and incorporating that feedback
into new design experiments.
A team structure that will allow the right decisions to be made on the fly.
Choosing a product architecture that allows for change rather than
attempting to get optimal performance.
Agile Principles 1
Satisfy the customer through early and continuous delivery of valuable software
Changing requirements are welcome, even late in development. Agile processes
harness change for the customer’s competitive advantage
Working software is delivered frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale
Business people and developers must work together daily throughout the project
Projects should be built around motivated individuals. If the right environment and
support is provided, the developers can be trusted to get the job done.
Agile Principles 2
face-to-face conversation is the most efficient way to communicate
Working software is the primary measure of progress
Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely
Continuous attention to technical excellence and good design enhances agility
Simplicity, the art of maximizing the amount of work not done, is essential
The best architectures and designs emerge from self-organizing teams
The team regularly reflects on how to become more effective, then tunes and
adjusts its behaviour accordingly.
The Agile Manifesto
written in February of 2001 by experienced software developers
Summarises agile development in four main values.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan.
Managing Risk
Schedule slips - Short release cycles
Project cancelled - Smallest release that makes sense
System goes sour - Maintain a suite of tests
Defect rate - Testing by programmers and customers
Business misunderstood - The customer is part of the team
Business changes - Short release cycles
False feature rich - Address only the highest priority tasks.
Different Agile Methodologies
Scrum
Extreme Programming (XP)
Dynamic Systems Development Method (DSDM)
Crystal Methods
Feature-Driven Development (FDD)
Lean Development (LD)
Adaptive Software Development (ASD)
Planning
Business people decide: Development team decides
scope estimates
priority of features technical consequences
composition of releases process
date of releases detailed scheduling
Planning Phases
Planning has three phases:
Exploration — learn what the system will eventually do: use cases (stories),
estimates
Commitment — choose the scope and date of next release: business sorts by
priority, development sorts by how well they can estimate, business sets the
scope
Steering — Team completes one development iteration and update the plan:
new uses cases as needed, re-estimate.
The Iron Triangle of Planning
Three constraints in project management
Scope (on spec)
The work to be done to deliver a working product.
Resources (on budget)
The budget and team members working to deliver and execute.
Time (on time)
When teams will deliver (releases and milestones).
 Waterfall vs Agile

FIXED FEATURES TIME COST

VARIABL
TIME COST FEATURES
E
Roadmaps
Most projects have a fixed budget, timescale and scope
How can you get away without a fixed scope?
Create a roadmap:
A prioritised list of features
The most important features are at the top
Guarantee a minimum level of capability.
Minimum Viable Product
Also Minimum Marketable Feature Set (MMF)
Need to deliver value quickly
Need to get early user feedback
Fewest number of features that deliver value to the customer
Domain Modelling
Problem Domain
The area of expertise covered by the project
Dev team need to understand this to solve the problem
Avoid being:
Over-specific / overly bounded
Too broad
Domain Model
A formal representation of a knowledge domain
Includes concepts, roles, relationships and rules
Implemented using a Web Ontology Language (OWL).
Benefits of a Domain Model
Helps control system complexity
Removes parts of domain not relevant to problem
Resolves ambiguities. Clear points
Purpose of a Domain Model
Reflects understanding of real world:
Entities
Relationships
Responsibilities

Can be represented as a simplified class diagram

Requirements Gathering
Requirements Gathering
The features your application will provide
Gathered from your customers
Used to guide the development process
Are you heading in the right direction?
Used to verify the finished product does as it should.
Features of Good Requirements
Clear
Unambiguous
Consistent
Prioritised.
User Stories
The unit of requirements gathering is the "user story"
Short descriptions of user-visible functionality
Can be developed within one iteration or less
Based on information from customers
Written by developers on file cards / post-it notes.
Features of User Stories
Captures the spirit
Ignores details
Make sense to customer
Delivers value to customer
End to end (full stack)
Independent
Testable
Small (1-5 days) so easy to estimate.
Format of User Stories
As a <user type>, I want to <function> so that <benefit>

As a consumer, I want shopping cart functionality to easily purchase items online.

As an executive, I want to generate a report to understand which departments
need to improve their productivity.
The 5 "Whys"
Need to ensure the user stories fit the business outcomes
Address the root cause of the business.
Apply the 5 whys
Process developed by Sakichi Toyoda
Avoids assumptions and logic traps
Traces the chain of causality.
Use Frequency
How frequently will the feature be used?
Important information to include in the user stories.

FREQUENCY
High, Medium, Low or
Hourly, Daily, Weekly, Monthly, Quarterly.
Value to User
How valuable is this story to the user?
Also needs to be added to the user stories.

VALUE:
High, Medium Low
User Story Examples
INVEST
Independent of all other user stories

Negotiable not a specific contract for user story as a result comes with finalize

Valuable having with identifiable value

Estimatable to a good approximation

Small so as to fit within an iteration

Testable. needs to be testable in order to be “done.”

Alternative User Stories
Most users will follow a similar flow through the product
These should be implemented first
What about the alternative paths/edge cases? Need to memorize

These need to be considered

Implementation is a lower priority.
Master Story List Need to memorize

The stories that define the end product

Should define the feature-complete system
Gives the development its sense of purpose and direction.
Use Case Detail Need to memorize

What level of goal are we trying to describe?

Alistair Cockburn in Writing Effective Use Cases
Visualise the goal level by thinking in terms of the sea
Sea level represents user goal level
Sky is high level (too high)
Below the surface is lots of detail (too much detail).
Goal Levels
Agile Planning Works
The result is what some would consider to be only a rough plan.
It works because:
the customers were involved
the release intervals are short, so mistakes become apparent
the customers continue to work with the development team
the plan is revised as needed.
Prioritisation and Planning
 Need to remember
MoSCoW Method padam karala nehe

User stories fit into four different priority groups:

Must Have: the top items will be essential
Should Have: next there will be the important but lower priority tasks
Could Have: next are the low priority features that will be completed
eventually
Would Be Nice: the tasks at the bottom may never be implemented.
Problems with User Stories
We can place the user stories in order of importance
Difficult to see the overall project plan
How will the user interact with the system
What will the process flow be?
Several proposed solutions:
Epics
Releases
User story mapping.
Epics
Simple approach is to group stories together
These are normally based on software releases
Agile term is epics.
Releases
A logical grouping of user stories
Make sense to the customer
Make sense to deploy as a group.
User Story Mapping
Releases and Epics don't capture the overall picture
User Story Mapping aims to solve these issues
Maps the user’s journey through your product
builds a simple model that tells your user’s story as you do.
Benefits of User Story Mapping
Helps:
Focus on the user requirements
Avoid feature arguments
Identifies:
Minimum viable product
Releases
Alternative stories.
Step 1 – Cards in Sequence
Step 2 – Filter by Criticality
Step 3 – Divide by Business Process
Step 4 – Identify Sprints
Step 5 – Identify Minimum Viable Product
Documentation
How Much Documentation?
Still a need for documentation:
Shared understanding of the project
Knowledge-base

But:
Live documents
Focus on building the software (don't get distracted)
Storing and Sharing Information
Information Radiator Information Icebox
Generic term for handwritten, Information kept out of sight
drawn, printed or electronic
Can be paper or electronic
displays
No-one can see it so no-one
Placed in a highly visible location
updates it
Everyone can see the latest
information at a glance