This is version . It is not the current version, and thus it cannot be edited.
Back to current version   Restore this version

Scrum Agile Development Framework#

Story

  • As a <role>, I want <a feature> so that I can <accomplish something>.
  • Each story increases the value of the product.
  • Each completed Story is a product increment.

Sprint

  • Short, sustainable burst of work that produces some completed Stories
  • 1-4 weeks, typically 2

Roles

  • Product Owner - 1
  • Scrum Master - 1
  • Team member - 7 +/- 2 (Scrum master is included)

Product Owner#


  • Maximize ROI
  • Record requirements, often as Stories, and adding them to the Product Backlog.
  • Direct the team
  • Control priorities or backlog
  • No one except the Product Owner may ask anyone to do work or set a priority
  • Holds the vision for the product
  • Represents the interests of the business
  • Represents the customers
  • Owns the Product Backlog
  • Sets priorities in the Product Backlog
  • Creates acceptance criteria for the Backlog Items
  • Is available to answer team member questions

Scrum Master#


Scrum Master acts like a coach keeping the team high-performing and self-organizing.
  • helps enforce SCRUM
  • constantly available
  • helps remove impediments or delays, facilitator
  • part of The Team and not a team boss

The Team#


  • 7 +/- 2 members (including Scrum master)
  • highly collaborative & self-organizing
  • do the work
  • have total authority on how the work gets done
  • determine tools and techniques
  • determine which Team Members will work on what
  • create and owns estimates
  • team members are not restricted to their area of specialty. They do whatever they can to help

Doing my job -> doing the job

What we are doing -> what is getting done

Scrum Artifacts#

===============

Product Backlog#


  • Contains all Stories
  • Each item is a backlog item or user story
  • Most important stories first
  • Stories on top must be manageable size and well understood
  • which users the story is for
  • brief description of functionality
  • the reason it is valuable
  • time estimate
  • acceptance criteria

Sprint Backlog#


  • Subset of the Product Backlog
  • Team to do list for the Sprint which is a list of Stories to be completed on that Sprint
  • Created by the Team (not the Product Owner)
  • Each Story is sub-divided into Tasks
  • Story = done by the Team
  • Task = done by a person

Burn Chart#


X = time, Y = Scope (task or story?)

Burn Up Chart = how much is done

Burn Down Chart = how much is left

(Turn tasks into points?)

Task Board#


Team's Tasks

Visible to everyone

Three columns: To do, Doing, Done

Use stickers that briefly describe the task

Team defines what "done" means. Post near Task Board.

Team declares a Story done as a group

Sprint Cycle (1-4 weeks, typically 2)#


Meeting = Ceremony
  • Sprint Planning - 2 hours - once per week
  • Daily Scrum - 15 minutes standing - daily - usually beginning of day
  • Story Time - 1 hour per week
  • Sprint Review - .5-1 hour for each week in the length of the Sprint - at end of Sprint
  • Retrospective - 1-2 hours for each week in the length of the Sprint - last meeting of the Sprint (after Sprint Review)

Development Period = Sprint = Cycle = Iteration

Sprint Planning Meeting#


At beginning of Sprint

Two parts: 1. Commit to a set of deliverables / Stories that the whole team believes is deliverable 2. what tasks make up the Stories

Part 1 (how many Stories)

  • Led by product owner
  • Bring up each Story in order
  • Discuss Story and completion criteria
  • Team members decide how many Stories they can complete in the Sprint
  • Product Owner decides which Stories, Team decides how many they commit to for that Sprint

Part 2 (how will we do it)

  • Run by the Team
  • Product Owner answers questions
  • May cause additions or subtractions to the Story list for the Sprint

Result of the Sprint Planning Meeting is the Sprint Backlog - list or Stories for that Sprint along with their associated Tasks.

Product Owner may need to negotiate the Stories.

Daily Scrum#


Inspect & Adapt

Each Team Member

  • what tasks I've completed since the last Scrum
  • what tasks I expect to complete before the next Scrum
  • what obstacles are slowing me down

If an obstacle is discovered, address after the meeting.

Story Time#


Discuss and adjust Stories in the Product Backlog, not the Sprint Backlog

Define & refine acceptance criteria

Each Story in the Product Backlog must include a clear pass/fail test criteria

  • Each Story needs an estimate
  • Stories at the top of the list must be small. Break big stories at the top of the list into smaller stories. Product Owner may do most of this with support from the Team.

Sprint Review#


Public meeting at end of Sprint. Invite stakeholders.

Good to get buy-in and show progress.

Discuss any Stories that have not been completed and why.

Demo the Stories that did get completed.

Receive feedback from stakeholders - inspect-and-adapt.

Not when Stories are declared done. That was done already. Also not the time to determine what is in the next Sprint.

Retrospective#


Private Team / Product owner meeting to discuss

what was learned and how to apply to the future

Not a laundry list of things that went well and things that didn't.

Identify one or two lessons that could be applied to future Sprints. It is about process improvement.

Add new attachment

Only authorized users are allowed to upload new attachments.
« This particular version was published on 16-Sep-2015 20:30 by BlakeMcBride.