SCRUM IN ACTION

1
OUTLINE

Models to Date Effort Estimation

Scrum in Action Managing the Sprint
Writing User Stories Task Board
Writing Accepteance Criteria Burn Down Chart
Use Cases vs User Stories Story Map
Scrum Reviewed
− The Process
− The Roles
− The Artifacts
− The Meetings

2
 ANALYSIS – REQUIREMENTS MODEL
TRADITIONAL ANALYSIS MODELS
Data Flow Diagrams ERD

OBJECT-ORIENTED ANALYSIS MODELS - UML

Use Case Diagram Domain Class Diagram Use Case Descriptions Activity Diagrams
USER STORY
(def) a high-level description of a requirement (i.e. functionality) that is
valuable to a user or product owner of the software product.
User Role – who?
Goal – what? functionality/feature
Reason – why? value adding

As a sales rep
I want to view a list of customers

so that I can pick one to contact.

4
ACCEPTANCE CRITERIA
Acceptance criteria provide clarity as to the expectation.
Contains 3 to 5 functional criteria regarding the user story
− what the user must be able to do
− what the user must not be able to do
− what the system must do

User Story Acceptance Criteria

As a sales rep, I want to view a list • Display all customer info by customer ID in
of customers so that I can pick tabular form.
• Include filtering & sorting.
one to contact. • Show total records & total visible records.
• Accessible from the main navigation menu.

5
USE CASES VS USER STORIES

Use Case User Story

As a sales rep, I want to view a
View Customer List list of customers so that I can pick
Customer
one to contact.

As a doctor, I want to view a

patient’s prescriptions so that I
View Patient Prescriptions
Doctor can look for drug to drug
interactions.

6
USE CASES VS USER STORIES – DESCRIBING EACH

Use Case User Story

As a sales rep, I want to view a
View Customer List list of customers so that I can pick
Customer
one to contact.

Use Case Description Acceptance Criteria

• Display all customer info by customer ID in
tabular form.
• Include filtering & sorting.
• Show total records & total visible records.
• Accessible from the main navigation menu.

7
SCRUM REVIEWED – THE PROCESS
• An iterative and incremental agile software development methodology.
• Frequent releases in short development cycles: 2 to 4-week sprints

Product Sprint
Backlog Backlog Increment
Sprint
Sprint Sprint
Review
Planning Sprint Execution Retrospective
(“Demo”)

Daily Scrum
+ Stakeholders
(“Stand-up”)

Task Burn Down

Board Chart

8
SCRUM REVIEWED – THE ARTIFACTS
Product Backlog Increment
• Product Owner • Potentially Shippable Product or
• Prioritized List of Product Backlog Items Potentially Deployable Product
(PBIs) • Product Owner decides when to release
• PBIs are written as user stories and
will have:
• Acceptance Criteria Managing Scrum
• Story Points/Effort Estimated
– by dev team Task Board
• For each item in the Sprint Backlog, list &
classify all tasks: To Do, In Progress, Done

Sprint Backlog Sprint Burndown Chart

• Development Team • Shows amount of work remaining
• List of PBIs committed to in one sprint
• Includes the Tasks for each PBI
Story Maps
• Organizaing user stories

9
SCRUM REVIEWED – THE ROLES

Product Owner Scrum Master

• client stakeholder who controls the Product Backlog • a facilitator
• removes impediments, resolves issues

Development Team
• 5-9 members
• Cross-functional skills
• “the developers”
• self-organizing teams
• complete control over organization & work processes
• They decide what goes in a Sprint

10
SCRUM REVIEWED – THE MEETINGS
Sprint Planning Daily Scrum (“Stand-Up”)
• 8 hours - Creating the Sprint Backlog • 15 mins daily – Status update w/in dev team
• Yesterday, Today, Barriers
• Part I: Product Owner presents the desired User • Attended by: Development Team, Scrum
Stories & the acceptance criteria for each story. Master

• Part II: Dev Team identifies tasks for each story;

creates time estimates per task; Sprint Review (“Demo”)
finalizes the user stories they can commit to. • 4 hours - inspect & adapt the product;
add new items to product backlog
• Dev Team gets to say if there are details lacking in • Attended by: Product Owner, Dev Team,
the user stories & cannot commit to certain stories Scrum Master PLUS: stakeholders

• Attended by: Product Owner, Dev Team, Scrum

Master Sprint Retrospective
• 3-hours - Process improvement
• lessons learned, successes & failure
• Attended by: Scrum Master, Dev Team

11
SCRUM REVIEWED – ADDITIONAL MEETINGS
Backlog Refinement – “Grooming”
• Refining the next items on the product backlog to
prepare for the next sprint(s).

• It includes:
• Clarifying backlog items
• Reducing Epics into smaller items
• Determining dependencies
Epic - a large
• Task can be done during a Sprint Planning Meeting Backlog item
but many prefer to do this in a separate meeting
(e.g. toward the end of a sprint).
An Epic is a feature that is
too broad/complex to be
completed in 1 sprint and
should be split into
multiple stories.

12
MANAGING SCRUM: EFFORT ESTIMATION – STORY POINTS
Fibonacci Sequence: 1, 2, 3, 5, 8, 13 - The sum of the 2 numbers to the left.
User Story
A
0 1 1 2 3 5 8 13 21 34
Assume: User Story B is about half the difficulty of User Story A.
• With Fibonacci, you will never see half of any number! It forces you to think!
• Is this user story a little more difficult than half (i.e. 5)?, or
• Is it a little less difficult than half (i.e. 3)?

T-Shirt Sizing: S, M, L, XL

13
MANAGING SCRUM: TASKBOARD
A quick visual way for everyone to see how the project is going.
It is the focal point during the Daily Scrum.
Task Board
User Story To Do In Progress Done
As a Sales Rep, I want to view
a list of customers so that I
can pick one to contact.

As a Sales Rep, I need to

maintain client data &
locations so that we can
properly determine their
product needs based on their
profile.

14
Task Board
User Story To Do In Progress Done
As a Sales Rep, I want to
view a list of customers so
that I can pick one to 4. Design 2. Modify the 1.Review the
5. Test the User Story
contact. the UIs Domain CD
UIs details

3. Create a
sketch
of the UIs

As a Sales Rep, I need to

maintain client data &
locations so that we can 3. Create a 2. Modify the 1.Review the
sketch Domain CD User Story
properly determine their of the UIs details
product needs based on
their profile.
5. Test the
4. Design UIs
the UIs

15
MANAGING SCRUM: BURNDOWN CHART
Sprint Burndown Chart
Assess how much work has been completed
Used by Scrum Masters at the Daily Scrum & Sprint Retrospective meetings
Story Points

16
MANAGING SCRUM: STORY MAP
Useful when we have a lot of user stories and we need to understand how
to progress through them.

17