The document provides an overview of Agile software development using Scrum. It describes Scrum as an Agile framework that focuses on delivering business value through short iterative development cycles called sprints. Key aspects of Scrum include self-organizing cross-functional teams, prioritized product backlogs maintained by a Product Owner, and regular sprint planning, daily standup, review and retrospective meetings facilitated by a Scrum Master.

1. Agile SW Development
with Scrum
http://tiny.cc/RcgcB
Aniruddha Ray

2. Presumptions
Audience is (well) aware of traditional SDLC methods
1)Waterfall Model
2)V Model
3)Spiral Model
4)Iterative Development (RUP)
And concepts like:
1)Requirements Traceability
2)Use Cases
3)Unit testing

3. Introduction
Learning Driven
Continuous Team Communication
Deliver in Short, Business-Focused
Phases, Typically 2 – 3 Months
Develop in End-to-End Functional Slices
Continuously Integrate Code
Throughout (Daily Builds)
Fully-Automated, Continuous Testing at
Both Functional and Unit Level
Low Cost of Change
Plan Driven
Infrequent Team Communication
Deliver Once in “Big Bang” Fashion,
Typically 9 – 12 Months
Develop in Layers: Presentation,
Persistence, Business, etc.
Integration of Different Layers Occurs
at End of Build Phase
Testing as Separate Phase at End of
Project, Emphasizing Functional Level
High Cost of Change
Waterfall Agile
Attempts to Nail Down Requirements
Expects, accommodates Changes
to Requirements

4. What is Agile ?
Agile proponents believe
Current software development processes are too heavyweight or cumbersome (Too many
things are done that are not directly related to software product being produced)
Current software development is too rigid
Difficulty with incomplete or changing requirements
Short development cycles (Internet applications)
More active customer involvement needed
Agile methods are considered
Lightweight
People-based rather than Plan-based
Several agile methods
No single agile method or definition
XP most popular in Development
Scrum most popular in Project and Delivery Mgmt
Agile Manifesto closest to a definition
Set of principles
Developed by Agile Alliance

5. The Agile Manifesto
A Statement of Values
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
While there is value in the items on the right, we value the items on the left
more.
Key signatories:
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
http://www.agilemanifesto.org

6. Agile Principles
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
Deliver working software 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.
Build projects around motivated individuals. Give them the environment and support they
need,
and trust them to get the job done.
The most efficient and effective method of conveying information to and within a
development
team is face-to-face conversation.
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, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts
its behavior accordingly

7. Agile Methods
Major Methods
Scrum – Ken Schwaber and Jeff Sutherland
Extreme Programming – Ron Jeffries and Kent Beck
Adaptive Software Development (ASD)
Dynamic System Development Method (DSDM)
Lean Software Development – Mary Popendieck
Other Methods
Kanban for SW Development
Feature Driven Development (FDD)
Crystal Framework – Alistair Cockburn
IUP (and RUP done with Agile Principles) – IBM (Rational)
Agile Modeling (Agile Data) – Scott Ambler

8. Agile In Practice
Focus on business value
Work together closely as one team
Work in short iterations
Inspect and Adapt
Remove waste ruthlessly (wasted effort, wasted time)
Deliver working software early and often

9. Scrum in 100 words
Scrum is an agile process that allows us to focus on delivering the highest
business value in the shortest time.
It allows us to rapidly and repeatedly inspect actual working software (every
two weeks to one month). – INSPECT and ADAPT
The business sets the priorities. Our teams self-manage to determine the
best way to deliver the highest priority features.
At every (pre-decided) frequency (two weeks to a month) anyone can see
real working software and (decide to release it as is or) continue to
enhance for another iteration.
The iterations (Sprints) are Time-Boxed.

10. A Short History of Scrum
1995:
- Design of a new method: Scrum by Jeff Sutherland & Ken Schwaber
- Enhancement of Scrum by Mike Beedle & combination of Scrum with XP
1996:
- Introduction of Scrum at OOPSLA conference
2001:
- Publication “Agile Software Development with Scrum” by Ken Schwaber & Mike
Beedle
2005:
- Scrum and XP were the most popular Agile frameworks implemented
(a lot of times Hand in hand)
2009:
- Scrum is the single most popular Agile implementation.
With popularity there is criticism or frustration of failure in some cases (Scrum-
But)

11. The Power of Scrum
More business value delivered sooner
Better return-on-investment for projects
Greater visibility – to team and customers (also –
Management)
Improved productivity – People, Process
Less waste – Lean mindset
Higher quality – Inspect and Adapt Frequently
Stronger teams – focussed, decisive, self managing
Better morale across the whole team - camaraderie
Engineering processes improved significantly
The critical features built at the quickest time at the
minimal cost

12. The Dangers of Scrum
It’s hard!
It requires significant change
It makes all dysfunction visible
- Scrum doesn’t fix anything: the team has to do it
- You may see things you don’t want to see
It demands honesty and transparency
Bad products will be delivered sooner, and
doomed projects will fail faster
Partial adoption may be worse than none at all
Be forewarned: many Scrum adoptions fail

13. Scrum in a Page

14. The Operating Model
“Self-managing or self-organizing” teams – no decision from
anyone else.
Product progresses in a series of month-long “sprints” –
TimeBoxed
Requirements are captured as features/stories in a “product
backlog” – One version of truth
Features are prioritized (by Business value or any other
parameter) by single Owner
At the end of every sprint team should demo a “potentially
shippable product”.
No specific engineering practices prescribed – team selects the
necessary tools and practices (can select from other Agile FW)
One of the many “agile” frameworks – TEAM takes best practices
from others if they want BUT for the RIGHT reasons

15. Characteristics
“MUST HAVE”
Teams have a dedicated PO and SM
SM is co-located with team
Team have a Scrum/War room.
Time Boxing of Sprints.
Scope of Sprint Backlog can be changed ONLY by Team (not SM or PO or Management)
Sprint Demo at the end of every sprint
No one changed PBL except PO
Team decides the scope of Sprints.
“GOOD TO HAVE”
Teams of sizes 5-7
Co-located teams and “war room”
Tie up with Engineering specific from XP (Test Driven Development, Refactoring)
Minimum Documentation (as per need)
SM not the People Manager or Traditional Manager
No management influence on team. Coaching from SM.
PO co-located with Team

16. Scrum Framework
Roles :
Product Owner, ScrumMaster, Team
Ceremonies :
Sprint Planning, Sprint Review, Sprint Retrospective, &
Daily Scrum Meeting
Artifacts :
Product Backlog, Sprint Backlog, Burndown Chart, Velocity
Chart

17. Product Owner
Responsible for maximizing the project’s ROI
Creates high-level vision (MRD or PRD???)
Creates a prioritized list of features (the Product Backlog) –
decides on parameter of prioritization
Final decision-maker on the Product Backlog – one version
of truth!!
Evolves the Product Backlog from Sprint to Sprint
Helps the team be effective, by removing waste (like
impediments and distractions) and supporting the team’s
Scrum practices and efforts to improve.
Can interact with customers, management or others to
refine product vision.
Single point of reference for team on ANY product related
issue.

18. Scrum Master
Serves the Team
Helps the Team remove obstacles and problems (“blocks”)
Facilitates interactions within the Team, and between the Team and
Product Owner
Protects the Team
Protects the team from outside disruption or threats
Coaches the Team
Helps the Team and Product Owner improve the effectiveness of
their practices
Helps the Team and Product Owner face and resolve difficult or
uncomfortable issues
Guides the skillful use of Scrum
Teaches Scrum to the Team, Product Owner, and company
Ensures that all standard Scrum practices are followed
Avoid having the team’s manager be ScrumMaster
Try having full time ScrumMaster for best results

19. Scrum Team
Typically 7 (+ or – 2) people
Co-located
100% dedicated to sprint (minor exceptions – Sys-Admin etc)
Cross-functional
QA, Programmers, UI Designers, etc.
Includes all the skills necessary to produce an increment of
potentially shippable product
Team takes on tasks based on skills, not just official “role”
Teams are self-organizing and self managing
What to do if a team self-organizes someone off the team??
Ideally, no titles but rarely a possibility
Team decides how much to commit to in a sprint
Team works together to manage and complete the work to achieve
the goal
Membership can change only between sprints

20. Ceremonies
Project Kickoff Meeting
Sprint Planning Meeting
Product Backlog Refinement Meeting
Sprint Review Meeting
Daily Scrum
(Scrum of Scrums) – for bigger teams
Sprint Retrospective Meeting

21. Project Kickoff Meeting
A special form of Sprint Planning Meeting – Optional.
Meeting before the begin of the Project – 1 day of
effort.
Team (or a smaller core) may go through the product
vision and entire backlog at higher level
Helps in understanding the big picture – reviewing
priorities and identifying dependencies/assumptions.
May result in first cut of High Level estimates or minor
refinements/changes in PBL (only PO will do it)

22. Sprint Planning Meeting
1st Part:
Creating/Refining Product Backlog (Edits, Reprioritization)
Determining the Sprint Goal.
Participants: Product Owner, Scrum Master, Scrum Team
2nd Part:
Participants: Scrum Master, Scrum Team
Creating Sprint Backlog
Discussing, Noting details on each scoped feature
Dependencies/Assumptions (P.O available on call for
discussion)
Note: ScrumMaster facilitates the meeting and protects the team from
pressure

23. Spring Planning Meeting
Suggested Steps
1) Team calculates how much time it will have
available during the Sprint
2) Team takes first item from Product Backlog and breaks it
into tasks
3) Team estimates how long the tasks will take (take care
of all planned activities, definition of DONE and buffer)
4) If there’s available time remaining, move to the next
item on Product Backlog and repeat 1-3
5) Finalize the features which have clarity and estimates
and decide on how many to be scoped for sprint.

24. Spring Planning Meeting – Input Output
Sprint Planning
Meeting
Product Backlog
Team Capabilities
Business Conditions
Technology
Current Product
Sprint Backlog
Sprint Goal

25. Sprints
Scrum projects make progress in a series of “sprints”
Analogous to XP iterations
Target duration is pre decided. Scrum suggests 2
weeks to one month
a constant duration leads to a better rhythm
Once decided Sprint duration MUST not change
Product is designed, coded, and tested during EACH sprint
EACH sprint should end in a potentially shippable code.
Scope DOESNOT change within a sprint.
Team may decide to push unfinished items to next sprint.
PO can decide to CANCEL a sprint midway and restart (in
special cases)

26. What is A Sprint
A 2 - 4 week long iteration, during which team
increments the product functionality
NO outside influence can interfere with the Scrum team
during the Sprint
Each Sprint begins with the Kickoff meeting
Daily Scrum Meeting conducted throughout the sprint.
Each Sprint ends with a sprint demo and retrospective.
Sprint duration or scope is immutable (unless critical
business change happens)
Sometimes teams may have intermediate Sprint review
meetings (to discuss/pre-plan items of next sprint if it
helps)

27. Sequential vs. Overlapping Dev.
Requirements Design Code Test

28. Scrum Meeting
Goal of the Scrum Meeting
Keep team coordinated and up-to-date with each other
Surface “blocks” or problems daily
Key Parameters
Daily (fixed time)
15-minutes or less (no more)
Stand-up
Not for problem solving
Only SM and Team
Three questions for everyone:
1. What did you do yesterday
2. What will you do today?
3. What obstacles are in your way?
“Chickens” and “Pigs” – Only “Pigs” can talk
Help avoid other unnecessary meetings
No discussion until after meeting ends
After meeting SM will help remove the blocks and find solutions to problems.

29. Scrum Meeting – FAQs
Is NOT a problem solving session
Is NOT a way to collect information about WHO is behind the schedule
Is a meeting in which team members make commitments to each other and to
the Scrum Master
Is a good way for a Scrum Master to know (Track?) the progress of the Team
Is THE meeting for a Scrum Master to know what is blocking the Team.
• Why daily?
– “How does a project get to be a year late?”
• “One day at a time.”
– Fred Brooks, The Mythical Man-Month.
• What if all team members are not present
– WHY are they not present (root cause?) – Burn Out, Low Team Morale or Over Pressure?
• Can Scrum meetings be replaced by emailed status reports?
– No
• Entire team sees the whole picture every day
• Create peer pressure to do what you say you’ll do

30. Sprint Review Meeting
Goal
Get hands on with what’s been built
Inspect the quality
Come up with ideas for improvements
See whether the commitment was completed
Team presents what it accomplished during the
sprint
Typically takes the form of a Demo of new features
No PowerPoint Demo
Informal
2-hour prep time rule
2 hour demo time
Participants – EVERYONE
Informal and Fun

31. Sprint Retrospective Meeting
Goal
Find ways to improve the team’s way of working in the next
Sprint
Participants: SM and Team only
Product Owner and managers should join for part (but not all) of
the Retrospective
Team needs time to talk by itself
Feedback within team and self correcting decisions – SM to check
that there is no outside imposition.
Three questions (optional 4th)
Start - What are worth trying
Stop – What are waste and should be stopped
Continue – What went well
Escalation/Risk List to Upper Management.
Don’t skip ever (Critical for the first 5-6 sprints!!!)

32. Product Backlog Refinement –
Optional
Optional Meeting – Worked well in some cases
Goal:
During the Sprint, plan to spend ~5% of your available time
doing Product Backlog Refinement
(also known as Product Backlog Grooming)
Team and Product Owner sit down and look ahead at
Product Backlog Items for upcoming Sprints
Team asks questions and clarifies requirements for
upcoming items
Team suggests items to add to the Product Backlog
Team starts to think about how they’re going to
implement the items (at a high-level)

33. Product Backlog
A list of all desired work on the project
Usually a combination of
story-based work (“let user search and replace”)
task-based work (“improve exception handling”)
List is prioritized by the Product Owner
Typically a Product Manager, Marketing, Internal Customer, etc.
• Requirements for a system, expressed as a prioritized list of Backlog Items
• Is managed and owned by a Product Owner
• PO Can use MOSCOW tool to prioritize.
• Can be a Spreadsheet (typically) or any other report
• Usually is created during the first Sprint Planning Meeting or Project
Kickoff Meeting
• Should be changed/updated and re-prioritized before each Sprint
Planning Meeting.
• Product Backlog will have all features (including non- functional
requirements)

34. From Sprint Goal to Sprint Backlog
Scrum team takes the Sprint Goal and decides what
tasks are necessary
Team self-organizes around how they’ll meet the Sprint
Goal
Manager doesn’t assign tasks to individuals
Managers don’t make decisions for the team
Sprint Backlog is created
Estimates are done by the team (best practice:
Wideband Modified Delphi method)

35. Sprint Backlog
A subset of Product Backlog Items, which define the
work for a Sprint
Is created ONLY by Team members
Each Item has it’s own status
Should be updated every day
No more than 300 tasks in the list
If a task requires more than 16 hours, it should be
broken down
Team can add or subtract items from the list. Product
Owner is not allowed to do it

36. Sprint Backlog during the Sprint
Changes
Team adds new tasks whenever they need to in order
to meet the Sprint Goal
Team can remove unnecessary tasks
But: Sprint Backlog can only be updated by the team
Estimates are updated whenever there’s new
information

37. Scalability of Scrum
A typical Scrum team is 6-10 people
Jeff Sutherland - up to over 800 people
"Scrum of Scrums" or what called "Meta-Scrum“
Frequency of meetings is based on the degree of coupling
between packets

38. Confused about Scrum?
How much Documentation: Scrum does not specify. Team decides (what’s
best for the project)
What are user stories: short, plain-language description of the feature, in
terms of customer value
What are 3 C’s: Card, Confirmation and Conversation. It’s a common model
for requirements/story analysis.
How do we estimate in scrum: Scrum doesn’t specify. Only suggestion is
to have 2 level of estimates – high level at PBL (may be Points) and low level
at Sprint BL (may be Hours). Also, ONLY the team decided on estimates.
Do we really need to release every sprint – 2 common approach -
Release every sprint and multi sprint release. Do what gives maximum
business benefit
How can team scope the sprint – Team is COMMITING to delivery. So they
should scope (Note: They may over or under-commit in initial sprints but with
the right spirit and coaching they should stabilize in 5/8 sprints. A disturbing
trend would continuous under or over-commitment)
Why should we track Velocity: The team needs to find a Self-sustaining
pace and confidence in commitment. Velocity provides the trend to them.
(Note: Velocity IS NOT for management to track)

39. Scrum EXPOSES Organization Impediments
Process
People arrive late to daily scrum and do not support basic discipline
Scrum meetings take too long – team is bred and considers the tie unproductive
Scrum master dictates design decisions or micromanages
Teams are too large for effective daily scrum and sprint planning
Teams do not report task-remaining time for burn-down analysis
People
Individuals are interrupted and tasked to work outside the sprint
Teams are isolated in cubicles and not in open scrum area
Teams members are not accountable for personal sprint commitments
Individuals are multiplexed across too many projects and teams.
Product
Cross-functional resources for definition, design, implementation, and test are not present on the team
Sprints do not fully implement and test potentially deployable increments of customer-valued features.
Product owner is not easily available or not integral to team
System integration is not forced at each sprint
Product owner won’t split up massive product backlog items to fit within a sprint
Team have ineffective resources for automating builds and integrations
Features are loaded into sprints after sprint begins

40. Thank You !!!

41. Burn Down Charts
Sprint Burndown
• Depicts the total Sprint Backlog hours remaining per day
• Shows the estimated amount of time to release
• Actually is not a straight line
• Can bump UP and DOWN
• Ideally should burn down to zero to the end of the Sprint
Release Burndown
• Will the release be done on right time?
• X-axis: sprints
• Y-axis: amount of hours remaining
• The estimated work remaining can also burn up
Product Burndown
Is a “big picture” view of project’s progress (all the releases)

42. Agile SW Dev – XP and RUP
Key characteristics of XP include
A team of five to ten programmers, co-located with customer representation on site.
Development with frequent builds and iterations, each of which is releasable and delivers
incremental functionality.
Requirements are specified as stories, each a chunk of new functionality the user requires.
Programmer work in pairs, follow strict coding standards, and do their own unit testing.
Requirements, architecture, and design emerge over the course of the project
Key characteristics of RUP include (Modified to IUP)
RUP provides a full lifecycle approach covering a series of product lifecycle phases called inception,
elaboration, construction, and transition
RUP provides a SW development method and a set of software engineering practices that cover
the majority of SW development disciplines.
RUP is iterative. Within each phase, the product undergoes multiple iterations; the nature of each
is determined in part by the life cycle phase.
RUP is incremental: Each iteration builds on the functionality of the prior iteration; the software
application evolves in this fashion with the benefit of regular and continuous feedback.

43. Agile SW Dev – DSDM and Lean
Key characteristics of DSDM include
Active user involvement
The team is empowered to make decisions
The focus is on frequent delivery of products
Fitness for business purpose is the essential criterion for acceptance of deliverables
Iterative and incremental development is necessary to converge on an accurate business solution.
All changes during development are reversible
Requirements are base-lined at a high level.
Testing is integrated throughout the life cycle.
Collaboration and cooperation between all stakeholders is essential
Key characteristics of Lean Software include
Reduced work in process inventory – Reduced investment in elaborated requirements, documented
designs
Reduced Cycle time – Build all software in much smaller lots
Cross-training and cell-based manufacturing – Increase cross-training with pair programming and
shared code assets. Have developers write tests as part of their code
Continuous Process Improvement – Continuous reflection and adaption

44. Scalability of Scrum

45. Does This Ring A Bell?