[UNDER CONSTRUCTION]

Notes from Scrum: A Breathtakingly Brief and Agile Introduction.

  1. Start with a bright idea
  2. Form a scrum team (product owner, scrum master, team members)
  3. Create a product backlog

Product Owner

  • responsible for maximizing the development team’s ROI (e.g., by directing the team toward the most valuable work, makese sure the team fully understands the requirements)
  • controls the priority of items in the team’s backlog (no one else on the team is authorized to change the order of backlog items)
  • responsible for recording requirements, usually in the form of user stories (e.g., “As a , I want , so that I can "), and adding them to the product backlog

Summary

  • holds the vision for the product
  • represents the interests of the business
  • represents the customers
  • owns the product backlog
  • prioritizes the items in the product backlog
  • creates acceptance criteria for the backlog items
  • is available to answer team members’ questions

User Stories

Each user story, when completed, will incrementally increase the value of the product (so each time a user story is done, we have a new product increment).

As a [type of user], I want to [do something], so that [some value is created].

Scrum Master

  • not a boss, a peer position, set apart by knowledge and responsibilites (i.e., not rank)
  • acts as a guiding scrum expert, champion/coach/facilator/guardian, seeking team cohesiveness, self-organization, and performance
  • the team’s deliverable is the product; the scrum master’s deliverable is a high-performing, self-organizing team
  • constantly available to the team, helping to remove any impediments

Summary

  • scrum expert and advisor
  • coach
  • impediment bulldozer
  • facilitator

Team Member

  • does the actual work and so has total authority over how the work gets done (e.g., what tools and techniques to use, who works on what tasks, etc.)
  • generates schedule estimates if they are needed by business needs
  • a specialist who is able to work outside of speciality in order to help deliver a potentially shippable product in each sprint

Summary

  • completes user stories to increase incrementally the value of the product
  • self-organizes to accomplish all necessary work
  • creates and owns the estimates (if needed)
  • owns “how to do the work” decisions
  • avoids “not my job/specialty” thinking

Product Backlog

  • cumulative list of desired product deliverables, where products serve user needs
  • includes backlog items, also called user stories, which are anything meaningful and valuable to produce that satisfy (including features, bug fixes, documentation changes)
  • ordered by descending story importance
  • stories near the top should be small and well understood
  • stories further down the list can be larger and less well understood
  • each item should include the following information:
    • which users the story will benefit (who it is for)
    • brief description of the desired functionality (what needs to be built)
    • reason story is valuable (why it should be done)
    • estimate for how much work is required for implementation
    • acceptance criteria to know implementation is correct

Sprint Backlog

  • team to-do list for a given sprint
  • has a finite life-span (i.e., length of sprint)
  • includes: stories (i.e., unit-of-value deliverables) and associated tasks (i.e., units-of-work that must be accomplished in order to deliver stories); each story will normally require many tasks