Scrum is an efficient framework within which you can develop software with teamwork. It is based on agile principles.
This presentation will help you understand agile development in general and Scrum in specific. You will get familiar with its associated terminology along with appropriate examples.
3. Manifesto for Agile Software Development
Individuals and interactions over processes
and tools
Working software over comprehensive
documentation
Customer collaboration over contract
negotiation
Responding to change over following a plan
4. Principles of Agile Manifesto
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.
5. Principles of Agile Manifesto
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.
6. Principles of Agile Manifesto
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.
8. What is Scrum?Scrum
Scrum:
Is an agile, lightweight process
Can manage and control software and product
development
Uses iterative, incremental practices
Has a simple implementation
Increases productivity
Reduces time to benefits
Embraces adaptive, empirical systems development
Is not restricted to software development projects.
13. Product Backlog
Ever changing
Prioritized list
Owned by product owner
Spread sheet example
14. Sprint Backlog
Consists of selected PBIs negotiated between the
team and the Product Owner during the Sprint
Planning Meeting.
No changes are made during the Sprint that would
endanger the Sprint Goal.
Initial tasks are identified by the team during Sprint
Planning Meeting.
Team will discover additional tasks needed to meet
the Sprint Goal during Sprint execution
Visible to the team.
Referenced during the Daily Scrum Meeting
16. Product Increment
The Increment is the sum of all the Product Backlog
items completed during a Sprint and the value of the
increments of all previous Sprints. At the end of a
Sprint, the new Increment must be "Done," which
means it must be in useable condition and meet the
Scrum Team's definition of "Done".
The product capabilities completed during the
Sprints.
Brought to a usable, releasable state by the end of
each Sprint.
Released as often as the Product Owner wishes.
Inspected during every Sprint Review Meeting.
20. Sprint Planning Meeting
Stake-holders to refine and re-prioritize the Product
Backlog and Release Backlog and to choose the
goals for the next iteration, usually droved by the
highest business value and risk
Scrum team and Product Owner meet to consider
how to achieve the requests, and to create a sprint
backlog of tasks to meet the goals
21. Daily Standup Meeting
Three things to talk in 15 minutes
What did I accomplish yesterday?
What will I do today?
What obstacles are impeding my progress?
Why standup meeting?
Promote individual’s commitment to the team
Promote close working relationship
Identify issues in timely fashion
22. Sprint Review Meeting
During the sprint review, the project is assessed
against the sprint goal determined during the sprint
planning meeting. Ideally, the team has completed
each product backlog item brought into the sprint,
but it's more important that they achieve the overall
goal of the sprint.
Sprint review typically include the product owner,
the ScrumMaster, development team, and the
product sponsors or stakeholders.
23. Sprint Retrospective Meeting
The sprint retrospective is usually the last thing
done in a sprint.
The entire team, including both the ScrumMaster
and the product owner should participate.
The sprint retrospective is of 3 hours duration for a
four week sprint.
The sprint retrospective is a meeting facilitated by
the ScrumMaster at which the team discusses the
just-concluded sprint and determines what could be
changed that might make the next sprint more
productive.
24. Roles of Scrum Master
Works with the organization to make Scrum possible
Ensures Scrum is understood and enacted
Creates an environment conducive to team self-
organization
Shields the team from external interference and
distractions to keep it in group flow
Promotes improved engineering practices
Helps resolve impediments
Has a leadership role
Has no management authority over the team
26. Roles of Product Owner
Single person responsible for maximizing the return
on investment (ROI) of the development effort
Responsible for product vision
Constantly re-prioritizes the Product Backlog,
adjusting any long-term expectations such as release
plans
Final arbiter of requirements questions
Decides whether to release
Decides whether to continue development
Considers stakeholder interests
May contribute as a team member
Has a leadership role
27. Roles of Development Team
Cross-functional (e.g., includes members with testing skills, and
others not traditionally called developers: business analysts, designers,
domain experts, etc.)
Self-organizing / self-managing, without externally assigned roles
Plans one Sprint at a time with the Product Owner
Has autonomy regarding how to develop the increment
Intensely collaborative
Most successful when located in one team room, particularly for the
first few Sprints
Most successful with long-term, full-time membership. Scrum moves
work to a flexible learning team and avoids moving people or splitting
them between teams.
6 ± 3 members
Has a leadership role
28. Sprint Burndown Chart
Summation of total team work remaining within one Sprint.
It is updated daily.
May go up before going down.
Intended to facilitate team self-organization.
Fancy variations, such as itemizing by point person or adding
trend lines, tend to reduce effectiveness at encouraging
collaboration.
Seemed like a good idea in the early days of Scrum, but in
practice has often been misused as a management report,
inviting intervention. The Scrum Master should discontinue use
of this chart if it becomes an impediment to team self-
organization.
30. Scalability
Typical individual team is 7 ± 2 people
Scalability comes from teams of teams
Factors in scaling
Type of application
Team size
Team dispersion
Project duration
Scrum has been used on multiple 500+ person
projects
31. User Stories
Instead of Use Cases, Agile project owners do "user stories"
Who (user role) – Is this a customer, employee, admin,
etc.?
What (goal) – What functionality must be
achieved/developed?
Why (reason) – Why does user want to accomplish this
goal?
As a [user role], I want to [goal], so I can [reason].
Example:
"As a user, I want to log in, so I can access subscriber
content.”