The aim of agile methods is to reduce overheads in the software process (e.g. by limiting documentation) and to be able to respond quickly to changing requirements without excessive rework.
This presentation is about Scrum methodology. First it reviewed traditional SDM and then talk about Agile and Scrum
2. Content
âș SDM definition
âș Review traditional SDM
âș Agile methodology
â Definition
â Type
âș Scrum
â roles
â Artifacts
â Process
2
3. SDM
âș Software Development Methodology
âș A framework that is used to structure, plan, and control
the process of developing an information system
3
4. SDM
âș Software Development Methodology
âș A framework that is used to structure, plan, and control
the process of developing an information system
âș How to develop a software?
â Just code and fix
4
5. SDM
âș Software Development Methodology
âș A framework that is used to structure, plan, and control
the process of developing an information system
âș How to develop a software?
â Just code and fix
âș No overhead , Requires little expertise
âș No process, QC, Highly risky
5
1950s Code & fix
6. SDM
âș Software Development Methodology
âș A framework that is used to structure, plan, and control
the process of developing an information system
âș How to develop a software?
â Design, Code, Test, Maintain
6
1950s Code & fix
1960s Design-code-test-Maintain
7. SDM
âș Software Development Methodology
âș A framework that is used to structure, plan, and control
the process of developing an information system
âș Software Development Life Cycle
7
1950s Code & fix
1960s Design-code-test-Maintain
9. SDM
âș Software Development Methodology
âș A framework that is used to structure, plan, and control
the process of developing an information system
âș Software Development Life Cycle
â Waterfall
9
1950s Code & fix
1960s Design-code-test-Maintain
1970s Waterfall model
11. 11
Waterfall model
ï¶ You donât realize any value until the end of the project
ï¶ You leave the testing until the end
ï¶ You donât seek approval from the stakeholders until late in
the day
changes
Takes too long
skipped
13. SDM
âș Software Development Methodology
âș A framework that is used to structure, plan, and control
the process of developing an information system
13
1950s Code & fix
1960s Design-code-test-Maintain
1970s Waterfall model
1980s Spiral Model
1990s
V-model/Rapid application
development
2000s Agile methods
15. RUP
âș Inception: defining the scope and objectives of the project, as
âș well as the business case
âș Elaboration: capturing the crucial requirements, developing
and validating the architecture of the software system, and
planning the remaining phases of the project
âș Construction: implementing the system in an iterative and
incremental fashion based on the architecture developed in
the
âș previous phase
âș Transition: testing and releasing the system
15
19. What is agile
âș Agile
â readiness for motion, nimbleness, activity, dexterity in motion
âș Agility
â The ability to both create and respond to change in order to
profit in a turbulent business environment
â Companies need to determine the amount of agility they need to
be competitive
19
20. Agile method
âș The aim of agile methods is to reduce overheads in the
software process (e.g. by limiting documentation) and to
be able to respond quickly to changing requirements
without excessive rework
âș Light Weighted methodology
âș Small to medium sized teams
âș One of the most common methodologies
20
22. The principles of agile methods
22
Principle Description
Customer involvement Customers should be closely involved throughout the
development process. Their role is provide and prioritize new
system requirements and to evaluate the iterations of the
system.
Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment.
People not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own
ways of working without prescriptive processes.
Embrace change Expect the system requirements to change and so design the
system to accommodate these changes.
Maintain simplicity Focus on simplicity in both the software being developed and
in the development process. Wherever possible, actively work
to eliminate complexity from the system.
27. Agile benefits
âș Faster time to market
âș Minimize risk (short iteration)
âș Reduce overhead
âș Agile team
âș Better response to customer requirement
27
28. Agile challenges
âș Keep the interest of customers
âș Team members
âș Prioritizing changes can be difficult where there are
multiple stakeholders.
âș Maintaining simplicity requires extra work.
28
29. Agile Methods
âș Agile methods:
â Scrum
â Extreme Programming (XP)
â Adaptive Software Development (ASD)
â Dynamic System Development Method (DSDM)
â âŠ
âș Agile Alliance
â A non-profit organization promotes agile development
âș http://www.agilealliance.org/
29
31. Why Talk About Scrum?
âș Popular
âș Powerful
âș Easy to learn
31
32. Scrum has been used by:
âą Microsoft
âą Yahoo
âą Google
âą Amazon
âą Electronic Arts
âą High Moon Studios
âą Lockheed Martin
âą Philips
âą Siemens
âą Nokia
âą Capital One
âą Intuit
âą Intuit
âą Nielsen Media
âą First American Real Estate
âą BMC Software
âą Ipswitch
âą John Deere
âą Lexis Nexis
âą Sabre
âą Salesforce.com
âą Time Warner
âą Turner Broadcasting
âą Oce
32
33. Scrum
âș SCRUM is an agile, lightweight process for managing and
controlling software and product development in rapidly
changing environments.
â Iterative, incremental process
â Team-based approach
â developing systems/ products with rapidly changing
requirements
â Controls the chaos of conflicting interest and needs
â Improve communication and maximize cooperation
â Protecting the team form disruptions and impediments
â A way to maximize productivity
33
35. Requirements Design Code Test
Time
Rather than doing all of one
thing at a time...
Scrum teams do a little of
everything all the time
Shippable
Scrum Overview
39. Product Owner
âș What is the essence of the product owner role?
â a product owner should own the product on behalf of the
company.
â You can think of the product owner as the individual who
champions the product
â who facilitates the product decisions
â and who has the final say about the product,
39
41. Scrum Master
âș Responsible for enacting Scrum values and practices
âș Removes impediments
âș Ensure that the team is fully functional and productive
âș Enable close cooperation across all roles and functions
âș Shield the team from external interferences
âș A Scrum Master should never be the Product owner
42. Team
âș Typically 7 people (+/- 2)
âș Cross-functional
âș self-organizing
âș Membership should change only between sprints
âș Turns the product backlog into increments of potentially
shippable functionality
âș Show the deliverables to the product owner
43. Role; The Scrum Team
ï Scrum Teams are self-organizing and cross-functional.
ï The team model in Scrum is designed to optimize
1. Flexibility
2. Creativity
3. productivity.
Scrum Team
53. Product Backlog Item, PBI
A Product Backlog is a list of top-level requirements that are usually associated with a single
Project or Product.
54. Product Backlog
âș Is the list of requirements per product.
âș Is dynamic and in constantly evolution. (alive
document)
âș Prioritized by the product owner
â Risk, value, and necessity.
âș Reprioritized at the start of each sprint.
âș Product Backlogs items are usually stated as user
stories.
âș Should take around 10% of each sprint to review the
product backlog
55. Product Backlog
Backlog item Estimate
Allow a guest to make a reservation 3
As a guest, I want to cancel a reservation. 5
As a guest, I want to change the dates of a reservation. 3
As a hotel employee, I can run RevPAR reports (revenue-
per-available-room)
8
Improve exception handling 8
... 30
... 50
65. User story
âș User story essentials
âș Telling stories about the user experience
âș Mapping user stories based on experience
â using this useful template:
As a [type of user]
I want to [perform some task]
so that I can [reach some goal]
65
67. Product Backlog Item, PBI
A Product Backlog is a list of top-level requirements that are usually associated with a single
Project or Product.
68. Sprint backlog
âș Consists of the tasks the Team performs to turn Product
Backlog items into a âdoneâ increment.
âș It is developed during the Sprint Planning Meeting.
âș It is all of the work that the Team identifies as
necessary to meet the Sprint goal.
âș One day or less is a usual size for a Sprint Backlog item
that is being worked on.
âș Only the Team can change its Sprint Backlog during a
Sprint
69. Tasks Estimate Assignee Sat Sun Mon Tue Wed Thurs
Code the user interface 16 8 4 4
Code the middle tier 50 16 12 10 4
Test the middle tier 40 6 7 9 11 8
Write online help 20 12
Write the food class 36 6 6 6 6 6 6
Add error logging 10 6 3
âŠ. ..
70. Sprint Burn Down Chart
âș Is a graph of the amount of Sprint Backlog work
remaining in a Sprint across time in the Sprint
Hours
40
30
20
10
0
Mon Tue Wed Thu Fri
50
79. Scrum Process
Sprint
1- Sprint Planning Meeting (2-4 Hours)
Part One: What will be done this Sprint?
Part Two: How will the chosen work get done?
1
2- Daily Scrum Meeting (15 m)
What has been accomplished since the last meeting?
What will be done before the next meeting?
What obstacles are in the way?
2
3 - Sprint Review (1-2 Hours)
Release âDoneâ Backlog
3
4 - Sprint Retro (1-2 Hours)
4
80. Sprint Planning Meeting
Sprint Planning
Meeting
Product Backlog
Team Capabilities
Business Conditions
Technology
Current Product
Sprint Backlog
Sprint Goal
We should use 5% of our sprint time on this.
At most workplaces, 10% of the sprint is time boxed for this meeting.
81. Daily Scrum
15 minutes
What have you
done since the
last meeting
What will you do
before next
meeting
What is in your
way
Decisions
Do not digress
beyond
answering the
three questions
Product owner
gives updates
82. Sprint review meeting tasks
Scrum Master
âą Set the Agenda
âą Project reporting
âą Snapshot of sprint
retrospect
âą Address the stake
holders
Team
âą Present the product
increment
âą Present individual
stories
âą For every story â
demo development,
QA and
documentation
Product owner
âą Evaluate
functionality
âą Confirm the stories
that have fulfilled the
DONE criteria
âą Include surprises (if
any)
85. 85
Product Owner Responsibilities
Organize the backlog into
incremental releases
Specify objective acceptance criteria for
stories
âą Communicate Business Goals, Customer Goals, End User Goals
âą Coordinate involvement of SMEs, users, and business stakeholders
âą Coordinate with other product owners to insure coherence of product and releases
Create and maintain the product
backlog
Participate daily
Be available to answer questions
and clarify details on user stories
Verify stories are done based on
acceptance criteria
Evaluate product at end of
Sprint and add or remove
stories from backlog as
necessary
86. Definition of âDoneâ
This is the âDefinition of Doneâ for the Scrum Team and is used to assess when work
is complete on the product Increment.
Although this varies significantly per Scrum Team,
members must have a shared understanding of
what it means for work to be complete, to ensure
transparency.
89. Scrum of Scrums / Meta-Scrum
Scrum Master Product OwnerScrum team member
90. When to use
âș requirements are not clearly defined.
âș work is delivered in increments
âș work is measured and controlled
âș productivity is maximized by applying known
technologies
âș organizations are willing to do anything and everything
for a project to succeed
âș project is important and no one has confidence that any
existing approach will work.
âș control and management is Empirical
90
91. When to avoid
âș there isnât a flexible environment
âș corporate culture isnât conducive to this of development
environment
âș teams of developers are more than 10. Six is ideal.
âș Cost is a major issue
âș No management support
âș No formal training available
91
92. Ref
âș Mike Cohn, User Stories Applied: For Agile Software
Development, 2004
âș Mike Cohn , Succeeding with Agile : Software
Development Using Scrum, 2009
âș Iian Goldstein, Scrum Shortcuts without Cutting Corners:
Agile Tactics, Tools, & Tips, 2013
âș Kenneth S. Rubin, Essential Scrum: A Practical Guide to
the Most Popular Agile Process, 2012
âș Rachel Davies, Liz Sedley, Agile Coaching, 2009
Waterfall Development is another name for the more
traditional approach to software development
You complete one phase (e.g. design) before moving on to the next phase (e.g. development)
You rarely aim to re-visit a âphaseâ once itâs completed. That means, you better get whatever youâre doing right the first time!