Agile SCRUM Overview

Click here to load reader

  • date post

    14-Apr-2017
  • Category

    Technology

  • view

    91
  • download

    3

Embed Size (px)

Transcript of Agile SCRUM Overview

  • 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 customers 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 doesnt 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 90s.

    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 Teams 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

  • For any queries, please contact: [email protected]

    mailto:[email protected]