Skip to main content

The SCRUM Guide Summary

SCRUM

Referred from SCRUM guide by Jeff Sutherland and Ken Schwaber

Scrum is a framework for developing, delivering, and sustaining complex products

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value

Uses of Scrum:
Scrum was initially developed for managing and developing products. Starting in the early 1990s, Scrum has been used extensively, worldwide, to:
  1. Research and identify viable markets, technologies, and product capabilities;
  2. Develop products and enhancements;
  3. Release products and enhancements, as frequently as many times per day;
  4. Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use
  5. Sustain and renew products.

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.

Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation

SCRUM Values

  1. Commitment
  2. Courage
  3. Focus
  4. Openness
  5. Respect

SCRUM Empirical Process

  1. Transparency
  2. Inspection
  3. Adaptation

Sprint

  • Maximum of 1 month
  • Development Team can be between 3 to 9 excluding SM and PO

 

Stages

  1. Sprint Planning (max of 8 hours for 1 month sprint)
  2. Daily Scrum (What did yesterday, what will do today and any roadblocks) max in 15 minutes
  3. Sprint Review (max of 4 hours for 1 month sprint)
  4. Sprint Retrospective (max of 3 hours for 1 month sprint)

Protected Sprint

  1. Chickens(stakeholders) don’t talk in the scrum
  2. Sprint backlog is frozen
  3. Team authority over how work is completed
  4. Scrum artifacts and meetings are sufficient

Roles(Team)

  1. Product owner
    1. Solely responsible for managing Product Backlogs
    2. Responsible for Ordering the product backlog
    3. Responsible for Optimizing the value of the work done by dev team
    4. Assigning priorities to product backlog
    5. What goes on in sprint
    6. Responsible for maximizing the value of product and dev team
  2. Scrum master
    1. Scrum process
    2. Enforcer of scrum rules
    3. Facilitates the key scrum meeting
    4. Assumes servant leader role
    5. Service to Product Owner
      1. Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible
      2. Finding techniques for effective Product Backlog management
      3. Helping the Scrum Team understand the need for clear and concise Product Backlog items
      4. Understanding product planning in an empirical environment
      5. Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value
      6. Understanding and practicing agility
      7. Facilitating Scrum events as requested or needed
    6. Service to Development Team
      1. Coaching the Development Team in self-organization and cross-functionality
      2. Helping the Development Team to create high-value products
      3. Removing impediments to the Development Team’s progress
      4. Facilitating Scrum events as requested or needed
      5. Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
    7. Service to Organization
      1. Leading and coaching the organization in its Scrum adoption
      2. Planning Scrum implementations within the organization
      3. Helping employees and stakeholders understand and enact Scrum and empirical product development
      4. Causing change that increases the productivity of the Scrum Team
      5. Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization
  3. Development team
    1. 3/5 to 9 people who develop the product increment
    2. Self-organized, accountable and cross-functional
    3. How to develop and deliver the committed for the sprint
    4. No specific titles inside the team like developer, tester, SME, architect etc


Stakeholders
  1. Work with product owner to add the requirements in product backlogs

Sprint

Heart of the SCRUM.
Timebound process of maximum of 1 month which will result Done, usable and potentially releasable product increment
  • Product owner only can cancel the sprint before its period ends
  • Sprint can be cancelled if the goals of the sprint becomes obsolete

Sprint Planning

  • Max of 8 hrs for 1 month sprint
  • What works to be performed are the main agenda of this
    • What can be delivered in the Increment resulting from the upcoming Sprint
      • Development team works on forecasting the functionality that will be delivered
      • PO discuss the objective of the sprint and the goals need to be achieved
      • Input to the meeting
        • Product backlog
        • Latest product increment
        • Projected capacity of the development team for the sprint
        • Past performance of the development team
      • Development team can solely take the decision how many product backlogs can be taken in the sprint
    • How will the work needed to deliver the Increment be achieved
      • The selected product backlog along with the plan how it will be build called Sprint Backlog
      • Initial days of work are decomposed into small units of one day or less
      • Development team self organizes how to take the works planned for the sprint backlog
  • Sprint Goal is created during the meeting which guides development team why the increment build is needed.

Daily Sprint

  • 15 minutes event daily for the development team same time and possibly same place
  • DT plans what to work on next 24 hr
  • It helps in inspecting the work been done and forecasting the work planned next
  • Main agenda of discussion
    • 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?
  • SM ensures the meeting happens every day but its DT responsibility to conduct the same

 

Sprint Review

  • Held at the end of the sprint to inspect the product increment and adapt the product backlog if needed
  • Scrum team and stakeholders collaborate about what was done in the sprint
  • Max of 4 hr meeting for 1 month sprint
  • This meeting includes
    • 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 target and delivery 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
    • Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
  • The Output of the meeting is a revised Product Backlog potential input for the next sprint

Sprint Retrospective

  • Occurs after Sprint review and before next sprint planning
  • Max of 3 hr for 1 month sprint
  • Purpose
    • 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
    • Create a plan for implementing improvements to the way the Scrum Team does its work.

Artifacts


  1. Product Backlogs (features, bug fixes, new requirements)
    1. Work not yet completed
    2. Ordered from highest to lowest priority
  2. Sprint Backlogs (Sprint planning + Product Backlogs)
    1. Items to be completed in the sprint
    2. User story estimates in Story points
  3. Burn down chart
    1. Progress of current sprint, shows work left to do in the sprint
    2. Public, provides transparency into sprint
  4. Product Increment
    1. Potentially working software
    2. Functionality added incrementally during each sprint

Comments

Popular posts from this blog

Basic Agile

Agile Agile Manifesto Individual & Interaction value more than Process & Tools Working Software than Comprehensive Documentation Customer Collaboration than Contract negotiation Responding to change than following a plan Agile Alliance Crystal Pragmatic Programming Extreme Programming Adaptive S/W Development DSDM Feature Driven Development SCRUM Agile Principles Customer Focused Early and continuous delivery software Welcome changing requirements Deliver working software frequently Team Focused Business people and developers work together daily Build projects around motivated individuals Emphasis on face-to-face interactions Development focused Working software shows progress Sustainable development pace Require technical excellence and good design Remaining Simplicity Self-Organizing team Regular Team retrospective and Adaptation