Implementing Scrum

with Azure DevOps

Scrum Overview

Benjamin Day
Coach, Trainer, Author, Speaker, Architect

@benday | www.benday.com
 Scrum using Azure DevOps
Roles, Events, and Artifacts
Course
How to support the people
Overview
- Scrum Roles

Focus on streamlining delivery

Along the way…
- Definition of Done
- QA Testing
- Supporting practices
- Multiple teams
- Metrics & Dashboards
 Scrum Overview
Module
Overview What is Scrum?
- Roles
- Artifacts
- Events

Definition of Done
Focus and the delivery of requirements
Sprint Duration
Scrum Overview
Scrum Overview
What is Scrum?
“…a way to get work done as a team in small pieces at a time, with
continuous experimentation and feedback loops along the way to learn
and improve as you go.”

https://www.scrum.org/resources/what-is-scrum
What is Scrum?
A process for delivering done, working software in 30 days or less.
 First presented at the OOPSLA Conference
in 1995
Ken Schwaber
Who Created It? - https://www.scrum.org

Jeff Sutherland
- https://www.scruminc.com/
 The Scrum Guide:
The Official Rules of
Scrum

https://scrumguides.org/
https://app.pluralsight.com/library/courses/scrum-master-skills
Pieces of Scrum

Roles Events Artifacts

How It All Gets Started

Product Owner Idea Product

 Vision for the product
Every feature that might ever appear in the
product
Product Backlog Items (PBIs)
Product Backlog
- Features, Requirements, User Stories
Prioritized
- Top priority items at the top
- Items that deliver the most value at the top
 Everyone it takes to create the
done, working software
Development Team
Developers
My wish: “Delivery Team”
Everyone it takes to DELIVER
done, working software
 Think “coach for the team”
Helps the team to be productive
Scrum Master
Helps the product owner to be productive
Helps everyone focus on ‘Done’
The Scrum Team

Product Owner Developers Scrum Master

(Development Team)
 Product Owner
Developers
Roles in Scrum
Scrum Master
Collectively, the Scrum Team
 The Sprint
- Container for all the events
- 30 days or less
Sprint Planning
Events in Scrum
Daily Scrum
Sprint Review
Sprint Retrospective
 What are we going to do?
- PBIs for the sprint

How are we going to do it?

Event: - Tasks for each PBI
Sprint Planning Establish a Sprint Goal
- Short description of what we’re trying to do
in this sprint

Artifact: Sprint Backlog

 15-minute daily meeting
For the development team

Review team’s plan to deliver the Sprint Goal

Daily Scrum - How are we going to get to ‘Done’
Review progress & impediments

Inspect & Adapt every 24-hours

 One of two events at the end of the Sprint
Scrum team attends
Stakeholders are invited to attend
Sprint Review
The goal is to gather feedback
- Feedback on ‘Done’ features
- Feedback on the Product Backlog
 Last event in the Sprint
Scrum team attends
Sprint
Retrospective Goals:
- How did we do?
- How will we improve / change?
 Product Backlog
- All the features that might ever appear in the
product
- Prioritized
- Owned by the Product Owner

Sprint Backlog
Artifacts in Scrum - Plan for the current Sprint
- What are we going to do?
- How are we going to do it?
- Sprint Goal
Increment
- Done, working software at the end of the
Sprint
Definition of Done
Definition of Done
There is nothing more
important in Scrum than
knowing what ‘Done’ means.
Definition of
Everything that has to happen in order to call
Done a Product Backlog Item (PBI) ‘Done’
(DoD)
Why is DoD so important?
Why is DoD so important?
What goes wrong if the
Definition of Done is
unclear?
 Transparency
Finish line is unclear
No shared understanding of ‘Done’

Grumpy stakeholders / bosses / customers

What goes wrong - Tough to manage expectations
if DoD is wobbly? Technical Debt
- Little bits of “not-quite-done”

Poor, inconsistent estimation

Difficult forecasting the future
“Two second change” requests
DoD is lots more than just
“my code compiles and is
committed.”
Sample Definition of Done (DoD)
Development / Coder Testing Deployment & Ops
Code is written with unit tests Written QA test plan Known deployment & rollback
plan
Unit tests: >75% code QA tested by another team
coverage member Deployment plan reviewed by
Ops Team
Code merged to main branch Deployed & tested in Staging
environment Database changes reviewed
Compiles & unit test pass as by DBAs
part of an automated build Automated UI tests pass
Load Tested
Database schema objects in No ‘show-stopper’ bugs
version control Deployed to Production
Reviewed by the Product
Database upgrade script in Owner
version control
Passes PBI acceptance criteria
Code reviewed by another
team member
 Create one!
It can be overwhelming in the beginning

Define what “done” means now

Your Team’s First Your DoD will grow over time
Definition of Done
Discuss the DoD in your Sprint Retrospectives
(DoD) - Had trouble delivering something?
- Was it related to some missing item on the
DoD?
Consider creating “aspirational” items
Product Backlog Items
(PBIs) should be doable to
‘Done’ in one sprint.

Work on a PBI does not

span multiple sprints.
Your DoD probably does not
have anything to do with
your sprint length.
PBIs Should Be Doable to Done in One
Sprint
PBIs Done in One Sprint,
Work In Progress, and Risk
Product Backlog Items
(PBIs) should be doable to
‘Done’ in one sprint.
Work on a PBI does not
span multiple sprints.
Sample Definition of Done (DoD)
Development / Coder Testing Deployment & Ops
Code is written with unit tests Written QA test plan Known deployment & rollback
plan
Unit tests: >75% code QA tested by another team
coverage member Deployment plan reviewed by
Ops Team
Code merged to main branch Deployed & tested in Staging
environment Database changes reviewed
Compiles & unit test pass as by DBAs
part of an automated build Automated UI tests pass
Load Tested
Database schema objects in No ‘show-stopper’ bugs
version control Deployed to Production
Reviewed by the Product
Database upgrade script in Owner
version control
Passes PBI acceptance criteria
Code reviewed by another
team member
Yes. All of that.
It’s going to be ok.
It’s totally doable.

It’s not as hard as you might think.

It’s a good idea.
It helps you.
 Each PBI get sized smaller
Ideally, with 2 or 3 other PBIs in the Sprint
- Maybe more

Ideally, the team works together on only one

PBIs Get to ‘Done’ PBI at a time together
in One Sprint Teams should be held accountable as a unit
- Rather than individual accountability
Get one PBI done as a team and then move to
the next one
- Minimize Work in Progress (WIP)
 Creates focus
You know if you’re making progress
- Partial credit rots your brain
- “We’re about 80% complete”
Why is this good? You can entirely change your priorities every
sprint
- Nothing to clean up
- No partially done work
Delivering gradually is great for risk mitigation
How Do You Choose a Sprint Duration?
How Do You Choose Your Sprint
Duration?
 Two questions for the Product Owner
How long can you go without changing your
mind?
How Long Should - Shifting priorities
the Sprint Be? How long are you willing to go without
knowing if the team will deliver?
- Ability to absorb failures and delays
- How confident is the team?
Long Sprint vs. Short Sprint
• Infrequent changes • Infrequent changes
of priorities of priorities
• High confidence in • Medium confidence
team to deliver in the team

4 3
weeks weeks

1 2
week weeks
• Constantly shifting • Frequent priority
priorities shifts
• Low confidence in • Average confidence
the team in the team
Product Backlog Items
(PBIs) should be doable to
‘Done’ in one sprint.

Work on a PBI does not

span multiple sprints.
Your DoD probably does not
have anything to do with
your sprint length.
My Sprint Length
Two weeks
Recommendation
Thoughts on Scrum with Azure DevOps
How to Be Successful with Scrum and
Azure DevOps
Pro Tip #1:
Garbage in. Garbage out.
Pro Tip #2:
Keep it simple
Pro Tip #3:
Assume Azure DevOps is
right…for now
 Azure DevOps won’t make you good at Scrum
Azure DevOps helps you to keep track of your
work
Garbage in.
Get the human stuff right and Azure DevOps
Garbage out. will feel easy

Get the human stuff wrong and Azure DevOps

will feel wrong
 Work up to “awesomeness”
Don’t try to adopt everything at once
- Gradual change
Keep It Simple
Use Azure DevOps to focus on ‘Done’
- Done, delivered software is the point
- Let Azure DevOps help you with that
 Try not to customize
The Scrum & Agile Process Templates are
pretty good
Assume Azure You can do just about everything you need
DevOps is without any customizations
right…for now If something is hard or awkward…
- Perhaps you’re doing something sub-optimal
in human space
Eventually you’ll want to customize
 Scrum Overview

Summary What is Scrum?

- Roles
- Artifacts
- Events

Definition of Done
Focus and the delivery of requirements
Sprint Duration
Planning & Managing a Product Backlog