Embed Size (px)
Citation preview
By
PHANI BHUSHAN NAGULAISTQB Adv TM, ISTQB CTFL, ISTQB CAT, TMMI-P,
CSM, PRINCE2 Practitioner, SSGB, ITIL V3 Foundation
Agile SCRUM Overview
INTRODUCTION TO AGILE
Introduction to Agile Model
Formulated in 1999 by Kent Beck, Ward Cunningham and Ron Jeffries.
In the Agile approach, each project is broken up into several ‘Iterations’.
All Iterations should be of the same time duration (between 2 to 8 weeks).
At the end of each iteration, a working product should be delivered.
In simple terms, in the Agile approach the project will be broken up into 10 releases
(assuming each iteration is set to last 4 weeks).
Rather than spending 1.5 months on requirements gathering, in Agile software
development, the team will decide the basic core features that are required in the
product and decide which of these features can be developed in the first iteration.
Introduction to Agile Model
Any remaining features that cannot be delivered in the first iteration will be taken up in
the next iteration or subsequent iterations, based on priority.
At the end of the first iterations, the team will deliver a working software with the
features that were finalized for that iteration.
There will be 10 iterations and at the end of each iteration the customer is delivered a
working software that is incrementally enhanced and updated with the features that were
shortlisted for that iteration.
Agile Manifesto
01 Our highest priority to satisfy the customer through early and continuous delivery of valuable software.
07 Working software is the primary measure of progress.
02 Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
08 The most efficient and effective method of conveying information to and within development team is face-to-face conversation.
03 Deliver working software very frequently, from a couple of weeks to couple of months, with a preference to shorter timescale.
09 Continuation attention to technical excellence and good design enhances agility.
04 Business people and developers must work together daily throughout the project.
10 Simplicity – the art of maximizing the amount of work not done – is essential.
05 Build projects around motivatedindividuals. Give them the environment and support they need, and trust them to get the job done.
11 The best architectures, requirements, and designs emerge from self-organizing teams.
06 Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Values of Agile Manifesto
Individuals and Interactions Over Processes and tools
Working Product OverComprehensivedocumentation
Customer Collaboration Over Contract Negotiation
Responding to Change Over Following a Plan
The Agile Manifesto argues that although the concepts on the right have
value, those on the left have greater value .
SCRUM
What is SCRUM?
SCRUM is an iterative and incremental agile software development methodology for
managing product development.
SCRUM doesn’t detail the process, it left to the team.
SCRUM is a light weight framework for managing the process.
Light weight means, keep overheads small to maximize the amount of productive time
available for getting useful work done.
History of SCRUM
Jeff Sutherland and Ken Schwaber conceived the Scrum process in the early 90’s.
They codified Scrum in 1995 in order to present it at the Oopsla conference in Austin,
Texas (US) and published the paper “SCRUM Software Development Process”.
Ken and Jeff inherited the name ‘Scrum’ from the 1986 groundbreaking paper ‘The New
Product Development Game’ by Takeuchi and Nonaka.
The Scrum framework for software development implements the principles described in
this paper for developing and sustaining complex software products.
History of SCRUM
Scrum was first tried and refined at Individual, Inc., Fidelity Investments, and IDX (now GE
Medical).
In February 2001, Jeff and Ken were amongst the 17 software development leaders
creating the Manifesto for Agile Software Development.
The Agile Alliance was founded with Ken Schwaber being its first chairman.
In 2002, Ken Schwaber founded the Scrum Alliance with Mike Cohn and Esther Derby,
with Ken chairing the organization.
In 2006, Jeff Sutherland created his own company, Scrum.inc, while continuing to offer
and teach the Certified Scrum courses.
Why is it called SCRUM?
Jeff borrowed the term SCRUM from an analogy put forth in a 1986 study by Takeuchi and
Nonaka.
Takeuchi and Nonaka compare high performing, cross functional teams to the scrum
formation used by Rugby Teams.
A scrum in England versus Scotland international.
SCRUM Theory
SCRUM is founded on empirical process control theory or empiricism.
Empiricism asserts that the knowledge comes from experience and making decisions
based on what is known.
Three pillars of empirical process control:
Transparency
AdaptationInspection
SCRUM Theory
Transparency• Significant aspects of process must be visible to
those responsible for the outcome.
Inspection• Scrum users must frequently inspect Scrum
artifacts and progress toward a Sprint Goal to detect undesirable variances.
Adaptation
• If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted.
• An adjustment must be made as soon as possible to minimize further deviation.
SCRUM ROLES
SCRUM ROLES SCRUM Roles
Product Owner
TeamSCRUM Master
Product Owner
Responsible for:
maximizing the value of the product and work of the development team.
Managing the product backlog. Product backlog management includes:
Clearly expressing the product backlog items;
Ordering the items in the product backlog to best achieve goals and missions.
Ensuring the product backlog is visible, transparent and clear to all.
Ensuring the team understands the product backlog items to the level needed.
Development Team
Typically 5-9 people
Cross-functional:
Programmers, testers, user experience designers, etc.
Members should be full-time
May be exceptions (e.g., database administrator)
Teams are self-organizing
Ideally, no titles but rarely a possibility
SCRUM Master
To Product Owner
• Finding techniques for effective Product Backlog management;
• Helping the Scrum Team understand the need for clear and concise Product Backlog items;
• Understanding product planning in an empirical environment;
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
• Understanding and practicing agility; and,
• Facilitating Scrum events as requested or needed.
To the Development Team
• Coaching the Development Team in self-organization and cross-functionality;
• Helping the Development Team to create high-value products;
• Removing impediments to the Development Team’s progress;
• Facilitating Scrum events as requested or needed; and,
• Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
To the Organization
• Leading and coaching the organization in its Scrum adoption;
• Planning Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact Scrum and empirical product development;
• Causing change that increases the productivity of the Scrum Team; and,
• Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
Chicken and Pig Story
SCRUM EVENTS
SCRUM Events
Time-box of one month or less.
Sprint ceremonies include:
Sprint Planning
Daily SCRUM Meeting
Sprint Review
Retrospective
Sprint Planning
Sprint Planning
Meeting
Product Backlog
Team Capabilities
Business Conditions
Technology
Current Product
Sprint Backlog
Sprint Goal
Sprint Planning
A collaborative meeting in the beginning of each Sprint between the Product Owner, the
Scrum Master and the Team.
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint.
Sprint Planning answers the following:
What can be delivered in the Increment resulting from the upcoming Sprint?
How will the work needed to deliver the Increment be achieved?
Daily SCRUM
The Daily Scrum is a 15-minute time-boxed event.
During the meeting, the Development Team members explain:
What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting
the Sprint Goal?
Sprint Review
Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
The Product Owner explains what Product Backlog items have been “Done” and what has
not been “Done”;
The Development Team discusses what went well during the Sprint, what problems it ran
into, and how those problems were solved;
The Development Team demonstrates the work that it has “Done” and answers questions
about the Increment;
The Product Owner discusses the Product Backlog as it stands. He or she projects likely
completion dates based on progress to date (if needed);
The entire group collaborates on what to do next, so that the Sprint Review provides
valuable input to subsequent Sprint Planning;
Review of how the marketplace or potential use of the product might have changed what
is the most valuable thing to do next; and,
Review of the timeline, budget, potential capabilities, and marketplace for the next
anticipated release of the product.
Sprint Retrospective
The purpose of the Sprint Retrospective is to:
Inspect how the last Sprint went with regards to people, relationships, process, and
tools;
Identify and order the major items that went well and potential improvements; and,
Create a plan for implementing improvements to the way the Scrum Team does its
work.
SCRUM ARTIFACTS
SCRUM ARTIFACTS SCRUM Artifacts
Product Backlog
BurndownChart
Sprint Backlog
Product Backlog
The Product Backlog lists all features, functions, requirements, enhancements, and fixes.
Product Backlog items have the attributes of a description, order, estimate and value.
Product Backlog is a living artifact.
Product Backlog refinement is the act of adding detail, estimates, and order to items.
Product Backlog is managed by Product Owner.
Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan
for delivering the product Increment and realizing the Sprint Goal.
Tasks are estimated in hours, usually 1-16.
Tasks with more than 16 hours are broken down before starting working on them.
Team members sign up for tasks, they aren't assigned.
Estimated work remaining is updated daily.
Any team member can add, delete or change the Sprint Backlog (theirs or new)
Work for the Sprint emerges
If work is unclear, define a Sprint Backlog with a larger amount of time and break it
down later
Update work remaining as more is known, as items are worked
Sprint Burndown Chart
The Scrum Burndown Chart is a visual measurement tool that shows the completed work per day against the projected rate of completion for the current project release.
Definition of Done (DOD)
DOD is used for deciding when an activity from the Sprint Backlog is completed.
Usable, working, delivered, deployed, potentially shippable
A checklist defining a quality standard.
Everyone must understand what Done means.
All increments must meet this standard.
The SCRUM Team increases the definition of done over time.
Benefits of SCRUM
Client Perspective
• Scrum puts the control of the value stream back in the hands of the business
• Scrum delivers products more quickly
• Scrum allows clients to change priorities and requirements quickly
Organization Perspective
• Scrum keeps an organization honest and helps them to meet their commitments
• Scrum promotes transparency; you no longer need to hide the truth, you can be open and honest with everyone
• Decision making is shifted to the lowest level (line employees), to the people best able to understand all of the facts
Management Perspective
• Better workforce management
• Enhanced customer and client relationships
• Visibility into the entirety of the project management process
• Motivated and inspired team members
Benefits of SCRUM
Product Perspective
• Improved credibility with your clients due to a higher quality product
• More predictable release cycle with built-in testing processes leads to product stability
• Sprint Review leads naturally to a product that the client wants and is excited about
Team Perspective
• Unlock the true potential of the team
• Create a safe working environment where people can thrive
• The team learns to achieve a sustainable pace, so that they can continue to be productive over the long haul
