Three Roles: Product Owner, Scrum master, Team

The Product owner: Own and prioritizes the Product Backlog

1. defines and prioritizes features--owns the gathering of requirements
2. agrees to iteration ground rules--set length of calendar time for sprint (2,3,4 weeks typical)
3. does not interfere with sprint(no scope creep)
4. can pull the plug at any time(has the power)
5. honors rules and the scrum process during sprints

Scrum Master: A Boundary Manager, Facilitates the Scrum process, Not a traditional Project manager

1. supports the team, facilitates the daily scrum meeting.
2. asks each developer: what do you do yesterday? what are you doing today? what is in your way?
3. listens and watches carefully during scrum meeting
4. pays carefull attention to non-verbal cues
5. removes impediments in way of team
6. secures resources(monitors, rooms, etc)
7. communicates to Product Owner

The team

1. participates in design to gain understanding of problem/solution space
2. selects subset of prioritized product backlog for sprint comment: estimates the effort, fills the timebox with work, commits to the work as a team
3. self organizes: everyone commits to all tasks neccessary during the sprint, determines the nature of self-organization
4. teams select work for each sprint
5. teams self-organize
6. teams have a velocity

Team velocity: how much work the team can average per iteration, for that team

1. each time has a personality
2. each team is unique
3. teams velocity becomes very predictable over time

Three ceremonies: Sprint Planning, Daily Scrum, Sprint Review(retrospective)

ceremony #1: Sprint Planning Meeting

1. Product Owner reviews: vision, roadmap, release plan
2. team reviews: estimates for each item on backlog that is a candidate for the sprint
3. team pulls the work: from the Product Backlog onto the Sprint Backlog

Ceremony #2: The Daily Scrum

1. By and for the Team
2. Other may attend and NOT speack
3. Team members speack, others listen
4. Team stays on task with the 3 questions, devergences are addressed offline outside of this meeting
5. visibility, clear understanding on a day-by-day basis

Product owners know the score on a daily basis, can pull the plug at any time

Ceremony #3: Sprint Review Meeting

Part 01: Product Demo

　　Led by Product Owner

Part 02: Sprint Retrospective

　　Led by Scrum Master

　　What worked?

　　What didn't?

　　What adjustments can we make now?

Three Artifacts: Product Backlog, Sprint Backlog, Burndown Chart

Artifact #1: Product Backlog

1. A list of features, prioritized by business value
2. Each feature has an associated estimate, provided by the ACTUAL team who will do the work
3. Backlog items come in from deverse sources, including the Team

Artifact #2: Sprint Backlog

1. Topmost subset of the Product Backlog, loaded onto the Sprint's "timebox"
2. usually has more detail attached, including planned hours and primary person responsible to do the work during the Sprint
3. Is the list of work the Team is addressing during the current Sprint

Artifact #3: Burndown Chart

1. Provides visibility into the Sprint
2. Illustrates progress by the team
3. Work on the Horizontal, Time on the Vertical

Three Best Practices: User Stories, Planning Porker, Scrum Board

Best Practices #1: User Stories

1. Plan-english requirements, written on common 3*5 index cards
2. Form: As a type of user, I want to [perform a specific action] such that [result]
3. Example: "As a web user, I want to make a reservation, such that I may secure my lodging"
4. Stories that are big are called EPICS
5. Acceptance criteria goes on card back

Best Practice #2: Planning Poker

1. A way for the team to do estimates
2. Each participant has cards numberd 1,2,3,5,8,13,21
3. Values represent 'story points' of effort
4. Players discuss feature, then throw down a card together
5. Differences are noted and discussed, then process repeats till a concensus estimate is formed

Best Practice #3: Scrum Board

1. Scrum Board is a rows-and-columns depictions of work-in-progress
2. Items of work are rows, work status lables are columns
3. Work is addressed from top to down
4. Work migrates from left to right on the board