Introductions
SCRUM what?!?
Raise your hand at the one that applies.
• Your level of experience with Scrum?
– Novice
– Somewhere in Between
– Expert
• How do you feel about Scrum?
– Skeptic / Doesn’t work
– In between
– Strong Advocate
Modeling Summary
Iteratively and continuously, understand users, refine requests into lightweight requirements that meet there's needs and our product / project then create just enough specs so that we can build
Context (product vision, business case)
Stakeholders
Product ownerRequirements
Scrum Team
Requirement – More than Just a Story
• Matured request that identifies attributes, capabilities and qualities that a system must possess for it to provide value
• A key component a user story or other concise expressions of a request
• Provides perspective to envision enough of the implementation possibilities to assign a story point estimate and re-prioritize
Requirement, more than a just a user story, enough to plan
User Stories
User story template is simplistic, it helps us remember a need while providing content
As a driverI want to find a conveniently located branch So that I can minimize travel time
User, User role, Persona (WHO?)
Specifies the primary beneficiary, others ca also use.
Desired Function (WHAT?)
End Result (WHY?)What is not specified and why?
User Stories - Samples
First attempt with context
As a user
I want to modify system users
We want administrators to be able to assign access privileges to users based on their role to secure access to functions and data based on need to know / do.
Improved, Good Enough?
Specification, Ready to Build
To be confident we can complete our sprint work just enough specs, just in time, to allow us predictably build
• Often we need nothing more than the requirement and a quick conversation
• We may also benefit essential use cases, prototypes, API signatures ,sample XML, etc. to clarify external or internal design
Spec RequirementsAdditional
ConversationsExamples /
Designs
Context (Project Vision, Design Standards, etc.)
Discovery Sessions at a Glance
Description
Series of facilitated sessions to orient team to the project’s business value, the process, and one another, while preparing to excellence. Not part of Scrum Framework but often helpful.
Duration
One day – multiple weeks
Attendees
Team, Product Owner, Key Stakeholders, Scrum Master, Subject matter experts
Outputs:
• Product Vision• Project approach• Team norms• Team rooms• Business process
definition
• Initial backlog• Dev. + test
environments• Dependency list• Risk list• Etc.
Discovery, aka Iteration 0
• Agile Process Training
• Product Discovery
• Product Roadmap
• Initial system design
• Architecture spike
• Collaborative modeling workshop
• Feature and epic prioritization and estimation
• Team Discovery
• Team norms and core hours
• Sprint duration
• “Ready” and “Done” definition
• Team structure (core / extended)
• Stakeholder / Project interactions
• Process Discovery
• Process value stream map
• Supplier customer diagram
• Key metrics (CTQs)
• Project Discovery
• Sponsor vision and business context
• Preliminary release planning
• Preliminary sprint planning
• Major dependencies and risks
• Environment
• Version control and build environments
• Team room
• Team board
Sample Discovery Session(s) might include:
Release Planning at a Glance
Description
Optional, but recommended project planning session, to review initial Product Backlog and set production Release dates.
Duration
Depends on team maturity, ideally under one day.
Attendees
Team, Product Owner, Scrum Master, Subject matter experts
Outputs:• Referred product backlog with initial /
updated estimates and priorities• Updated release plan• Updated roadmap
Two Levels of Estimating
Release planning estimates are
done with RELATIVE STORY
POINTS focusing on Size,
Complexity and Risk
3 is 50% bigger than 2
A modified Fibonacci sequence
1, 2, 3, 5, 8, 13, 20, 20 &
100
T-shirt sizes – XS, S, M, L, XL
Over time, story points
automatically encompass
external interruptions, technical
surprises, developer skill level,
unplanned absences, domain
knowledge and other factors
Doesn’t decay over time
Sprint Level estimating sometimes
includes a look at story points, and
sometimes task level estimating
Task hours
Task sub points
Estimate with Story Points - benefits
Relative measure of Size, Complexity and Risk
3 is 50% bigger than 2
A modified Fibonacci sequence
1, 2, 3, 5, 8, 13, 20, 20 & 100
T-shirt sizes – XS, S, M, L, XL
Over time, story points automatically encompass
external interruptions, technical surprises, developer
skill level, unplanned absences, domain knowledge
and other factors
Doesn’t decay over time
Based on “Wideband Delphi” convergent estimation
techniques
1. Each team member (estimator) has a deck of cards
2. Moderator (PO) reads a story and it is briefly
discussed
3. Estimators select a card & places it face down
on the table
1. Cards are turned over all at once
2. Outliers are discussed
3. Re-estimate is run until estimates converge
(or don’t!)
Estimation Try 1 Try 2 Try 3
Konstantin 3 5 5
Ivo 8 5 5
George 2 3 5
Monika 8 5 5
Planning Poker in Action
Planning Poker Approach 0. Define the meaning of 1
1. Each estimator has a card deck (whole team)
2. A Moderator (PO) reads a story and it is briefly
discussed
3. Each estimator selects a card and places it face
down on the table
4. Cards are turned over all at once
5. Differences (especially outliers) are discussed
6. Re-estimate until estimates converge (or don’t)
Velocity Basics
Sum of planned, completed functionality in
a Sprint, for example:
Team estimated 36 points worth of
stories during Sprint Planning
One story, worth 8 points was not
completed, the others were
Their current velocity is _____
points?
Work actually completed in prior sprints, all
things being equal, is a good predictor of
work that can be completed in the future
Effective is a release planning metric
Not effective as a productivity metric or
to compare across teams
Measure work completed, forecast future throughput
Product Backlog at a Glance
Discovery Session
Release Planning
Product Backlog
Production Ready
Features
BurndownSprint
Backlog
Sprint Planning
Daily Scrum
Work
Sprint Review
Sprint Retro
Start Sprint Daly Scrum End Sprint
Description
List of desired functionality for a project prioritized by business value by the PO
Managed by
• Contains requirements as “User Stories”
• Top priority stories are better defined
• DEEP• Detailed Appropriately• Estimated• Emergent • Prioritized
Key Characteristics
• PO / Scrum Master
Contains:• Prioritized Product Backlog Items or User Stories• Rough Estimates• Forecasted iteration boundaries• Release Dates
Sample Product Backlog
ID Backlog Item Acceptance Criteria Points Sprint
1 114 As a GuestI want to Make a ReservationSo that I can get a room of my choice
Confirmation e-mail is sent Must be made > 24 hours in
advance
2 S1
2 127 As a GuestI want to Cancel a ReservationSo that I can receive a full refund
Confirmation e-mail is sent Must be cancelled > 24
hours in advance
2 S1
3 109 As a GuestI want to change reservation dates
….. 4 S1
4 112 As a hotel employeeI want to see future reservations
…… 8 S2
… …. ….. …… …
41 416 …………. …… S99
Sprint at a Glance
Discovery Session
Release Planning
Product Backlog
Production Ready
Features
BurndownSprint
Backlog
Sprint Planning
Daily Scrum
Work
Sprint Review
Sprint Retro
Start Sprint Daly Scrum End Sprint
Description
Time boxed iteration that consists Of Sprint Planning, day to day Work , Daily Scrum, Sprint Reviewand Sprint Retrospective
Involves
• Isolated from further changesThat would affect Sprint Goal
• Work organized adaptively
• 1- 4 Weeks
Key Characteristics
Duration
• Team, Scrum Master, PO, SMEs
Outputs:• Daily updates of Burndown charts or CFD• Potential shippable functionality • Other necessary items, as prioritized by Product
Owner
Sprint Backlog at a Glance
Discovery Session
Release Planning
Product Backlog
Production Ready
Features
BurndownSprint
Backlog
Sprint Planning
Daily Scrum
Work
Sprint Review
Sprint Retro
Start Sprint Daly Scrum End Sprint
Description
List of desired functionality and tasks for the team to get productBacklog items to done in the current sprint
Managed By
• Created at Sprint Planning• Updated throughout Sprint as
tasks are added / removed
Key Characteristics
• Team, Scrum Master Outputs:• Prioritized User Stories & their constituent tasks• Task-level estimates (optional ) in hours• Other information necessary to understand the
work at hand
Sprint Planning at a Glance
Description
Meeting to elaborate, estimateand prioritize highest-value UserStories, creating Sprint Backlog
Duration
Attendees
Meeting to elaborate, estimateand prioritize highest-value UserStories, creating Sprint Backlog
Meeting to elaborate, estimateand prioritize highest-value UserStories, creating Sprint Backlog
Discovery Session
Release Planning
Product Backlog
Outputs:
• Estimate and Prioritized User Stories• Updated Acceptance Criteria• Sprint backlog Tasks ready
Production Ready
Features
BurndownSprint
Backlog
Sprint Planning
Daily Scrum
Work
Sprint Review
Sprint Retro
Start Sprint Daly Scrum End Sprint
Sprint Planning Preparation
Description
• Product Owners should arrive prepared to discuss top priority stories and ask any questions regarding alternative development paths
• The Scrum Master should arrived prepared with capacity planning and logistical information, such as who is in, whose is out, who is working from home, expected velocity, etc.
• Team members should have reviewed stories and determined initial estimates and questions about development scenarios
• Acceptance criteria should be clear and well articulated
• Depending on the needs of the team, other supporting material, like wireframes, should be created
Daily Scrum at a Glance
DescriptionDaily meeting to inspect progress against Spring goal, to make adaptations that optimize the value of the next days work.Focused on making trade-offs, coordinating efforts and risk management.
Duration10-15 minutes
AttendeesTeam, Scrum Master, optionally Product Owner and interested Stakeholders.
Outputs:• Updated Schedules• Task Board Updated• Risks and Issues Identified• Informal follow up meetings (Sit-Downs)
arranged
Initialmeeting
Discovery session
Release
planning
Product backlog
Sprint planning
Daily scrum
Work
Sprint Review
Sprint Retro
Ready features
Start of Sprint Daily End of Sprint
Sprint
Sprint backlog Burndown
Sprint Burndown: Summary
DescriptionSimple tool for Team to track progress during a Sprint
Key Characteristics• Shows work remaining, not
work completed• Traditionally have burned
down task hours, many now burn down story points
Ideal line shows the necessary angle for completion
Managed byTeam, ScrumMaster,
Represents Progress versus Plan:• Below the line good• Above bad• Trend is also important
Sprint Review at a Glance
Outputs:• New features on Product Backlog• Reprioritized Product Backlog• Revised Team or Project Structure
Initialmeeting
Discovery session
Release
planning
Product backlog
Sprint planning
Daily scrum
Work
Sprint Review
Sprint Retro
Start of Sprint Daily End of Sprint
Sprint
Sprint backlog Burndown
DescriptionPO identifies what has been done versus plan, team demonstrates completed functionality, and attendees collaborate on what to do next.
Duration4 hours for 1 month Sprint,2 hours for 2 week Sprint, etc.
AttendeesTeam, ScrumMaster, optionally Product Owner, optionally Users and Interested Stakeholders.
Ready features
Sprint Retrospective at a Glance
Outputs:• New features on Product Backlog• Reprioritized Product Backlog• Revised Team or Project Structure
Initialmeeting
Discovery session
Release
planning
Product backlog
Sprint planning
Daily scrum
Work
Sprint Review
Sprint Retro
Start of Sprint Daily End of Sprint
Sprint
Sprint backlog Burndown
DescriptionSM guides team to inspect how last Sprint went (people, relationship, process and tools) to identify “pluses” and deltas to create a plan for change with the framework for upcoming Sprints.
Duration3 hours for 1 month Sprint,1.5 hours for 2 week Sprint, etc.
AttendeesTeam, ScrumMaster, optionally Product Owner.
Ready features
Definition of Ready
“Don't let anything that's not READY into your Sprint, and let nothing escape that's not DONE.”
(Serge Beaumont about definition of ready)
“ Backlog must be READY before taking into SprintSoftware must be DONE at the end of the Sprint”(Jeff Sutherland in presentation)
Serge Beaumont: ‘READY is when the team says: "Ah, we get it“’.✓Why? Business value✓What? Outcome vision✓ How? Implementation strategy & cost✓ User story have been estimated, backlog is prepared for 1,5 -2 sprints.✓ Is the Granularity OK?