This document provides an overview of Agile software development principles and practices. It discusses:
- The problems with traditional waterfall software development approaches
- The evolution and principles of Agile development as outlined in the Agile Manifesto
- Key Agile practices like Scrum, product backlogs, sprints, and sprint planning meetings
- Tips for writing good user stories and splitting stories into smaller tasks
- The typical lifecycle of activities in a Scrum project including release planning, iterations (sprints), daily stand-ups, sprint reviews and retrospectives
2. Bhawani Nandan Prasad
Objective
To help you understand the principles of
Agile software development and
successfully implement the software
development life-cycle on your projects
3. Topics
Agile primer
Why Agile?
Mapping Agile to SDLC activities
Writing good requirements
A typical iteration in Scrum
Software engineering best practices
Wrapping up releases
Bhawani Nandan Prasad
4. Why bother about Agile?
Israel Gat: Cutter Consortium:
“Agile can do to software development what internet did to
computing”
“Agile is a train. Either you get on to it or you will be under it”
PMI research: Use of Agile has tripled from December
2008 to May 2011
Gartner: 80% of software development projects would
use Agile by end of 2012
74% of IT professional surveyed had practiced Agile in
some form or other; 55% for 2 years or more
Copyright (c) Sandeep Shouche, CSM, PMP,
PgMP, PMI-ACP 2012
5. Bhawani Nandan Prasad
Problems with Software Development
Excessively long “time to market” for products
Customer orientation is lacking
Cost of delivering software is too high
Poor productivity of teams
Too much “wasted work” to fix defects and rework designs
Software quality is poor
Ability to responding to change is low
Employee morale is low (and attrition rates are high!)
Project failure rate is too high
~70% or more
Delivered ROI falls short of expectations
10. Bhawani Nandan Prasad
Choosing Agile
• Are requirements for the finished project complete, clear and
stable?
• Can the effort required to complete the project be easily
predicted?
• Have you successfully completed previous projects similar to
the one you’re about to start?
If you can answer “yes” to these questions, then a plan-driven
process like the waterfall method is likely your best bet. Because
answering “yes” to these questions indicates the project you’re
about to start is predictable to a reasonable degree.
In short, If Project has three factors–urgency, complexity, and
novelty - choose agile
11. Bhawani Nandan Prasad
Traditional Software Development
Design
Coding
Testing
DeployAdvantage: Logically sound
Disadvantage: Assumes predictability!
Analysis
12. Bhawani Nandan Prasad
Evolution of Agile
Iterative development, done in small incremental
chunks, validating requirements at each step
Agile development evolved in mid-90’s – the
word “Agile” was adopted in 2001
Has significant parallels with “Lean movement”
in the manufacturing world
Is also similar to “spiral models”, except spiral
iterations are longer and rely on “prototypes,
where Agile emphasizes “working software”
14. Bhawani Nandan Prasad
Agile Manifesto – Feb 2001
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
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn,
Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith,
Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C.
Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
See http://www.agilemanifesto.org
15. Bhawani Nandan Prasad
Principles related to SDLC
Principle No.1: Our highest priority is to satisfy
the customer through early and continuous
delivery of valuable software.
Break it up to deliver early and frequently
Principle No.2: Welcome changing
requirements, even late in development. Agile
processes harness change for the customer's
competitive advantage.
Do not be bureaucratic about change management, be
flexible to absorb change
16. Bhawani Nandan Prasad
Principles related to SDLC
Principle No.3: Deliver working software frequently,
from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
Typical length of an iteration is 2 weeks to 2 months
Principle No.7: Working software is the primary
measure of progress.
The output of each iteration must be “working software”
Principle No.9: Continuous attention to technical
excellence and good design enhances agility.
Design is important, but design is “continuous” – not one time
activity
17. Agile Unified Process
Four project lifecycle phases
Inception
Elaboration
Construction
Transition
Six engineering disciplines
Business modeling, Requirements, Analysis and Design,
Implementation, Test, Deployment
Three supporting disciplines
Environment, Configuration and Change management, Project
management
Bhawani Nandan Prasad
19. Bhawani Nandan Prasad
Scrum Basics
Backlog
Item
Priority
Product
Owner
Inputs from Customers,
Team, Execs, Support,
etc.
Team
Sprint Backlog
Sprint Planning
Meeting
Sprint
1-4
weeks
Finished
Deliverables
Sprint
Review
Sprint
Retrospective
Scrum Master
Daily
Standup
Once agreed, Sprint end date &
deliverables do NOT change
20. Bhawani Nandan Prasad
Product backlog
List of everything that could ever be of value to
the business for the team to produce.
Defined in terms of “epics” and “user stories”
Ranked in order of priority
Priority is a function of business value and risk
Product owner can make any changes they want
before start of a Sprint / Sprint Planning meeting
It can be addition of new items, changing or
removing or existing items or re-ordering them
Ideally for 2 sprints items should be well defined
21. Bhawani Nandan Prasad
Example of Product Backlog
Description Size
Utility to mark all positions to market
at end of trading day 20
Report on outstanding positions for
SEBI filing 10
On-the-fly introduction of securities
into intra-day trading 5
Upgrade server platform to JRE 1.6
5
Fix intermittent problem with index
window flickering (Defect
No.0002413)
10
Integrate Mark-to-market utility with
trading system (execute every hour) 20
List of requirements in
descending order of
priority
Can be …
Functional or non-
functional
Technical upgrades
Significant bug-fixes
22. Bhawani Nandan Prasad
User Stories and Epics
Epic: High-level theme that combines a set of
planned features or requirements Examples …
Scalability improvements to handle processing rate of
100 transactions per second
Usability improvements
User Story: A short description of a planned
feature or requirement. Examples …
Modify server code to support multi-threading
Reduce the size of packets sent over
Reduce number of clicks to checkout to 5
Support Section 508 recommendations
23. Bhawani Nandan Prasad
Epics and user stories
Can include any or all of the following
New features
Modification or Deletion of existing features
Bug-fixes to existing software
Internal clean-up tasks like code re-factoring,
support for new technologies, etc.
Should all result in “adding value” to the
customer!
24. Bhawani Nandan Prasad
User Stories
Should be small
Typically no more than 40 man hours of effort
Should be deliverable as a unit (de-
coupled or loosely coupled)
Should be described in as much detail as
is necessary to “validate successful
completion”
May contain child stories or tasks
25. Writing good user stories
Example templates
As a [role], I can [feature] so that [reason]
E.g. As a account holder, I can check my balances online so that I can
maintain daily balance
Use 3”X5” index cards (ensure that you don’t write too much)
Make it testable by writing acceptance criteria
Given [context] <and/or [some more context]> When [event] Then
[outcome] <and/or [another outcome]
E.g. Given account balance is negative and no direct deposit is scheduled
on the day when the account holder tries to withdraw money then the bank
will deny the request and send the account holder an alert
Connect the dots by thinking of all possible scenarios
More references:
http://www.agilemodeling.com/artifacts/userStory.htm
Bhawani Nandan Prasad
26. Bhawani Nandan Prasad
How to split storiesRef: Bill Wake’s “20 Ways to Split Stories”: http://xp123.com/xplor/xp0512/index.shtml
The Big Picture
• Research vs. Action
If a story is too hard, one split is to spend some time researching solutions to it.
• Spike vs. Implementation
You can buy learning for the price of a spike (a focused, hands-on experiment on some
aspect of the system).
A spike might last an hour, or a day, rarely longer.
• Main Flow vs. Alternate Flows
(Use case terminology.) The main flow - the basic happy path - is usually the one with the
most value.
• Manual vs. Automated
If there's a manual process in place, it's easier to just use that for a while before throwing it
away.
• Buy vs. Build
Sometimes, what you want already exists, and you can just buy it. For example, you might
find a custom widget that costs a few hundred dollars. It might cost you many times that to
develop yourself.
Other times, the "off-the-shelf" solution is a poor match for your reality, and the time you
spent customizing it might have been better spent developing your own solution.
27. Bhawani Nandan Prasad
How to split stories
User Experience
Batch vs. Online
A batch system doesn't have to interact directly with the user.
Single User vs. Multi-User
Keep concurrency, access control issues, etc. in abeyance for
some time.
API-only vs. User Interface
It's easier to not have a user interface at all. For example, if
you're testing your ability to connect to another system, the first
cut might settle for a unit test calling the connection objects.
Generic UI vs. Customer UI
At one level, you can use basic widgets before you get fancy
with their styles. To go even further, something like Naked
Objects infers a default user interface from a set of objects.
28. Bhawani Nandan Prasad
20 ways to split stories
“Ilities”
• Static vs. Dynamic
It's easier to calculate something once than ensure it has the correct value every time its
antecedents change.
• Ignore errors vs. handle errors
While it's less work to ignore errors, that doesn't mean you should swallow exceptions.
Rather, the recovery code can be minimized.
• Transient vs. Persistent
Let's you get the objects right without the worries about changing the mapping of persisted
data.
• Low fidelity vs. High fidelity
You can break some features down by quality of result. E.g., a digital camera could start as a
1-pixel black-and-white camera, then improve along several axes: 9 pixels, 256 pixels,
10,000 pixels; 3-bit color, 12-bit color, 24-bit color; 75% color accuracy, 90% color accuracy,
95% color accuracy." (William Pietri)
• Small scale vs. large scale
"A system that works for a few people for moderate data sets is a given. After that, each step
is a new story. Don't forget the load tests!" (William Pietri)
• Unreliable vs. Reliable
"Perfect uptime is very expensive. Approach it incrementally, measuring as you go." (William
Pietri)
29. Bhawani Nandan Prasad
Typical life-cycle in a Scrum World
Repeated as long as it
takes to create a
releasable product
High-level Roadmap
For a Release
30. Bhawani Nandan Prasad
Release Planning
Aims at coming up with a “long-term roadmap”
What should happen during a release planning?
Prepare of a release roadmap with “epics” defined at high level
Estimate of what and how much can be accomplished in a
release
Identify and tie up dependencies on external factors or events
Prepare a high-level project plan with milestones
Mode of release planning
Usually face-to-face, lasting up to a week
The entire team need not attend– key representatives should
Product Owner and optionally other stakeholders can attend
Advance preparation (understanding epics, priorities,
dependencies, etc.) help this go faster
31. Bhawani Nandan Prasad
Sprints
Backlog
Item
Priority
Product
Owner
Inputs from Customers,
Team, Execs, Support,
etc.
Team
Sprint Backlog
Sprint Planning
Meeting
Sprint
1-4
weeks
Finished
Deliverables
Sprint
Review
Sprint
Retrospective
Scrum Master
Daily
Standup
Once agreed, Sprint end date &
deliverables do NOT change
32. Bhawani Nandan Prasad
Sprints!
Refers to an “iteration”
Typically 1-4 weeks long
Produces an enhanced version of the software
All engineering activities (Code, Unit Test, System,
Regression test) must be completed within the Sprint
Should be “near releasable quality”
A “release” or project contains multiple sprints
As many as is necessary to create substantial “value” to
the customer
34. Bhawani Nandan Prasad
Sprint Planning Meeting
Backlog
Item
Priority
Product
Owner
Inputs from Customers,
Team, Execs, Support,
etc.
Team
Sprint Backlog
Sprint Planning
Meeting
Sprint
1-4
weeks
Finished
Deliverables
Sprint
Review
Sprint
Retrospective
Scrum Master
Daily
Standup
Once agreed, Sprint end date &
deliverables do NOT change
35. Bhawani Nandan Prasad
Sprint planning meeting
Goal:
For the team to make good commitment around what it will
deliver by the end of the Sprint
What’s a Good Commitment?
Clearly understood by all
Shared among team
Achievable without sacrificing quality
Achievable without sacrificing “sustainable pace” (heijunka!)
Attended by Team, Product owner, Scrum Master
Usually take 1-2 Hrs for each week of Sprint duration
36. Bhawani Nandan Prasad
Sprint Calendar - Example
Mon Tues Wed Thurs Fri
3 4 5 6 7
10
Sprint
Planning
11
First day of
Sprint
12 13 14
17 18 19 20
Last day of
Sprint
21
Review &
Retrospective
24 25 26 27 28
37. Bhawani Nandan Prasad
How Sprint Planning should work
Clarifying questions about stories asked
Determine how many stories can “fit” into
a Sprint
Stories are broken down to tasks and
assigned to individuals
Estimates may be modified if necessary
Tip: Some pre-preparation (story-
grooming) helps make the meeting short
38. Bhawani Nandan Prasad
Sprint backlog (planning template)
Story Task Owner Estimate
Utility to mark all positions to
market at end of trading day
Generate and test query to get
open positions
Sanjay 2
Determine formula for M2M
based on regulations
Shreya 4
Call web service to custodial
services for margin calls
Kapil 8
Email notifications to account
owners about margin position
Manish 2
Write and execute unit tests Sanjay 8
Test story end-to-end Murali 16
Upgrade server to JRE 1.6 Changes to the build system
and installer
Larry 8
Try out latest patch of JRE 1.6
to make sure it works
Gaurav 16
Limited regression testing Alex 24
39. Bhawani Nandan Prasad
No changes during a sprint!
Once team has committed, no changes can be
made to the Sprint deliverables
Details will emerge during Sprint, but no new work
or substantially changed work
No Changes to Sprint Duration either
Sprint ends on planned date whether has
completed its commitment or not
The Product Owner can …
Change the Product backlog before the next Sprint
Terminate a Sprint (used very rarely)
40. Bhawani Nandan Prasad
The team
Backlog
Item
Priority
Product
Owner
Inputs from Customers,
Team, Execs, Support,
etc.
Team
Sprint Backlog
Sprint Planning
Meeting
Sprint
1-4
weeks
Finished
Deliverables
Sprint
Review
Sprint
Retrospective
Scrum Master
Daily
Standup
Once agreed, Sprint end date &
deliverables do NOT change
41. The team!
Usually 7 + or – 2
As low as 3 or as high as 15
Resources can be shared (but ideally should not be)
Can change between Sprints (but ideally shouldn’t)
Can be distributed (but better when co-located)
Is “cross-functional”
Has all the skills necessary to produce another increment of
“potentially shippable” product
Is “self-managing”
Is empowered enough to do whatever it takes to produce the
potentially shippable product, within organizational constraints
Bhawani Nandan Prasad
42. Bhawani Nandan Prasad
Daily Standup Meeting
Backlog
Item
Priority
Product
Owner
Inputs from Customers,
Team, Execs, Support,
etc.
Team
Sprint Backlog
Sprint Planning
Meeting
Sprint
1-4
weeks
Finished
Deliverables
Sprint
Review
Sprint
Retrospective
Scrum Master
Daily
Standup
Once agreed, Sprint end date &
deliverables do NOT change
43. Bhawani Nandan Prasad
Daily standup meetings
Ground-rules
Every weekday
Whole team attends
Everyone stands
15 minutes or less
Everyone reports three things
What was able to accomplish since last meeting
What will try to accomplish since by next meeting
What is blocking me
No discussion, conversation until end of meeting
44. Role of testing/QA in Scrum
No separate QA team
Quality is everyone’s responsibility
One team that is responsible for the
product delivery
No more adversarial relationship between Dev
and QA
QA is lot tougher with Agile
Near releasable quality each Sprint is a huge
challenge
Bhawani Nandan Prasad
45. Testing best practices
Continuous testing and regression
Automate as much testing as possible
Testers to participate in story elaboration
and estimation
Test early and test often
Close coordination between Developer and
Tester needed
Move towards “test driven development”
Bhawani Nandan Prasad
46. Test-Driven Development
Never write a single line of code until there
is a failed automated test
How to do it?
Design: Figure out what you want to do
Test: Write a test to express the design (it
should FAIL)
Implement: Write the code
Test again: Now the test should pass
Bhawani Nandan Prasad
47. Test frameworks/tools for TDD
Xunit
Junit (http://junit.org)
cppunit (http://cppunit.sourceforge.net)
Ruby
PHPunit
Jsunit
TAP (Test Anything Protocol)
http://testanything.org
Other test libraries
e.g. http://opensourcetesting.org
Use code coverage tools (e.g. Clover, Emma, Cobertura)
Bhawani Nandan Prasad
48. Bhawani Nandan Prasad
Orderly closure of Sprints
Backlog
Item
Priority
Product
Owner
Inputs from Customers,
Team, Execs, Support,
etc.
Team
Sprint Backlog
Sprint Planning
Meeting
Sprint
1-4
weeks
Finished
Deliverables
Sprint
Review
Sprint
Retrospective
Scrum Master
Daily
Standup
Once agreed, Sprint end date &
deliverables do NOT change
49. Bhawani Nandan Prasad
Sprint review
Purpose of Sprint Review
Demo (not just slides) what the team has built
Generate feedback which Product Owner can
incorporate in the product backlog
Decide about “release” of the builds to the
stakeholders (alpha, beta, etc.)
Attended by Product Owner, Managers,
Scrum Master and Team
Usually lasts 2 Hrs
50. Sprint “done” criteria
Software with all features work as defined by the
user story
All QA testing for completed features is done
with no pending defects
Regression tests pass
All documentation is completed
Planned stories demonstrated to the Product
Owner, Customer and other stakeholders
Bhawani Nandan Prasad
51. What happens if Done criteria are not
met?
Incomplete stories move to the backlog
and prioritized again before the next Sprint
Retrospective to determine why the plan
commitment was not met
Under no circumstances can you “extend”
a Sprint!
Bhawani Nandan Prasad
52. Bhawani Nandan Prasad
Sprint retrospective
What it is?
1-2 Hr meeting followed by each Sprint Review/Demo
Attended by Product Owner, Scrum Master, Team
What’s working and what could work better
Why does Retrospective matter
Accelerate visibility
Accelerate actions to improve
It’s a key mechanism of continuous improvements
(Inspect & Adopt)
53. Bhawani Nandan Prasad
How to make retrospectives effective
Have fun (e.g. bring in food, recognize star
performers from the previous sprint)
One person facilitates (Scrum Master)
Do not stifle opinion – collect all inputs
Arrive at few (2-3) things to change
Follow up!
Assign specific actions
Token penalty if improvements are repeated!
54. Bhawani Nandan Prasad
Engineering best-practices
Continuous integration: “Automated”
nightly builds
Mandatory code reviews (integrated with
code check-ins) and unit tests
Automated testing:
Sanity tests, executed daily
Regression tests, executed per iteration
Test-driven development
55. Bhawani Nandan Prasad
Wrapping up the release!
Once the work required for the release is done
Final readiness checks for a “release”
Can be preceded by one or more “hardening”
sprints
No new features added during hardening
Focus on fixing bugs, packaging, regression testing,
performance testing, etc.
Hardening sprints can be split across the release (need
not all be at the end)
Resist temptation to bank on hardening sprints to do
required bug fixes – it quickly turns into waterfall in
disguise
56. Release “done” criteria
Customer acceptance received
Beta feedback incorporated
Release documentation (e.g. Release Notes, Read me
First, etc.) is completed
Non-functional requirements (e.g. Performance,
Usability, etc.) are tested and validated
Regulatory and compliance requirements are met (e.g.
Section 508, ECCN, License agreements, etc.)
All planned integrations with other products are tested
and working
Bhawani Nandan Prasad
57. Bhawani Nandan Prasad
Release retrospective
What it is?
A retrospective session for an entire release
To draw lessons from the project and use for the future
Bring an orderly closure to the activities of a release
How to make it effective?
Bring in food!
Do some reward and recognition
Preferably bring an external facilitator
Run like a brainstorming session to generate ideas
Use mute mapping to prioritize ideas generated
58. Summary
Agile teams must master the art of working in
small increments and delivering quickly
Good engineering practices are of paramount
importance
QA must be built into the development process –
automated testing is indispensable
If we are able to delivery early, we create value
faster, and by getting feedback continuously, we
are better able to adapt to the changing
environment
Bhawani Nandan Prasad