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.