Skip to content

All.scrum.explanation

Refs#

  • From "Lacey, The Scrum Field Guide: Practical Advice for Your First Year, 2012"

Roles#

Goal of Scrum methodology#

  • Work in the interests of customers and stakeholders to turn the vision into a working product

Metaphor for the roles in terms of a race car#

  • ProductOwner = driver

  • DevTeam = engine

  • ScrumMaster = lubricants and sensors

ScrumMaster#

  • Identify when the team is not performing to its ability

  • Assist in correcting the issues

  • Notice non-verbal cues

  • Is comfortable with conflict

  • Can build trust and earn respect

ProductOwner#

  • Represent the customers

  • Point the car in the correct direction

  • Adjust the car direction to stay on course

  • Make decisions about official release

  • Ultimately he is responsible for success or failure of the projects

  • Decide:

    • What is developed
    • When it is developed
    • Whether the product meets expectations

DevTeam#

  • Aka Team, Development team, Core team

  • Developers, testers, architects, designers

    • Cross-functionality is a good thing
  • The ideal team size is 6 plus / minus 2

Artifacts#

Product backlog#

  • = master list of all features and functionalities needed to implement the vision into the product

  • The ProductOwner keeps the backlog:

    • Prioritized
    • Up to date
    • Clear
  • The backlog is never complete:

    • Items are added and removed
    • Reordered based on priority, value, or risk

Product backlog items#

  • Aka PBI

  • E.g., bugs, features, enhancements, non-functional requirements

Complexity of PBI#

  • ProductOwner and the DevTeam estimate the size of each task

  • The complexity of each task can be expressed in different ways:

    • Points
    • T-shirt size (S, M, L, XL)

High-priority vs lower-priority tasks#

  • High-priority stories should be small and clear

    • So they can be brought into the sprint
  • Lower-priority items can be large and fuzzy

    • Bigger stories are decomposed into smaller chunks

Sprint backlog#

  • = output of the planning meeting

  • List of tasks that need to complete during the sprint

  • Sprint backlog tasks have an estimate in hours

  • The DevTeam keeps the sprint backlog up to date

  • During a sprint

    • New tasks are discovered
    • Tasks are adjusted (in terms of description or estimated hours)
    • Tasks are marked as done

The burndown#

  • Communicate how much work is remaining and what is the team velocity

  • It is updated at the end of each day

  • Plot the number of hours remaining (y-axis) against the number of days remaining (x-axis)

The meetings#

Planning meeting#

  • Each sprint begins with a sprint planning attended by the team, ScrumMaster, ProductOwner
    • Typically one needs two hours per number of weeks to plan the sprint
    • For a 1-month sprint, 8 hours of meeting
    • For 2-week sprint, 4 hours of meeting

Part one of sprint planning meeting#

  • Review of potential product backlog items for the sprint

  • ProductOwner describes what the goal of the meeting is

  • DevTeam asks questions to drive away ambiguity

  • Outcome is one-sentence description of the desired outcome of the sprint

Part two of sprint planning meeting#

  • Many DevTeams discuss how to implement the tasks

  • The ProductOwner doesn't need to be present

  • The ScrumMaster can be present facilitating the process

  • The DevTeam discusses and decides the implementation of the tasks

  • Decompose backlog items into work tasks

  • Estimate tasks in terms of hours

Daily scrum#

  • Aka daily stand-up

  • Give the DevTeam the opportunity to sync daily, at the same time, and at the same place

Daily scrum: questions#

  • The 3 most frequent questions are:
    • What have you accomplished since the last meeting?
    • What will you accomplish today?
    • What obstacles are in your way?

What the daily scrum is not#

  • The daily scrum is not a deep-dive problem-solving meeting

    • Any other issues need to be taken offline
  • It is not a status report meeting to the ScrumMaster

    • The purpose is for the DevTeam members to talk to each other
  • The ProductOwner is in "listen-only" mode

Sprint review#

  • On the last day of the sprint, the DevTeam holds a sprint review

  • Everybody should join

    • ScrumMaster
    • ProductOwner
    • DevTeam
    • Customers, key stakeholders
    • Executives
  • DevTeam

    • Recaps the goal of the sprint
    • Presents the work done
  • Customers

    • Review the progress made on the project
    • Accept changes
    • Ask for changes

Sprint retrospective#

  • After the sprint review, the retrospective is a way to identify how to improve process and execution

Sprint retrospective: questions#

  • What went well during the sprint?

  • What could be improved in the next sprint?