IIT Academy: Scrum 103

SCRUM 103
HI Per Lean Practice
IIT Academy
Industrie IT
Scrum 103

SCRUM 103
Hello Scrum!
What do you know?
What have you done?
What don't you know but want to know?
What are you concerned/sceptical about?

SCRUM 103
Contents
1. Recap - Agile Manifesto
2. Scrum Ecosystem
3. Scrum Framework
4. Pre-Delivery
• People
• Work
5. Delivery
• Ceremonies
• Concepts
6. Appendix
a. Protips for standup
b. Kanban and Scrum
c. Scaling Scrum
d. Agile Coaching
e. High Performing Teams
f. Traditional cf. Agile
g. Acceptance Criteria

SCRUM 103
Recap: Agile Manifesto
1

SCRUM 103
VISIBILITY
INSPECTION
ADAPTATION

SCRUM 103
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it
and helping others do it. Through this work we have come to value:
individuals and interactions over processes and tools
working software over comprehensive documentation
customer collaboration over contract negotiation
responding to change over following a plan
That is, while there is value in the items on the right, we value the
items on the left more.

SCRUM 103
The Twelve Principles
1. Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software
2. Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage
3. Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to
the shorter timescale
4. Business people and developers must work together
daily throughout the project

SCRUM 103
5. Build projects around motivated individuals. Give
them the environment and support they need, and
trust them to get the job done
6. The most efficient and effective method of conveying
information to and within a development team is
face-to-face conversation
7. Working software is the primary measure of progress
8. Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely

SCRUM 103
9. Continuous attention to technical excellence
and good design enhances agility
10. Simplicity - the art of maximising the amount
of work not done - is essential
11. The best architectures, requirements, and
designs emerge from self-organising teams
12. At regular intervals, the team reflects on how
to become more effective, then tunes and
adjusts its behaviour accordingly

SCRUM 103
Attitudes to Change
Traditional
“change is the exception”
• disruptive
• implies a failure in planning
• can be feared/resented
• plan in order to avoid it
• control it tightly
Agile
“change is the norm”
• inherent part of the process
• implies learning
• is valued/welcomed
• look for opportunities to introduce it
• manage it flexibly

SCRUM 103
Scrum Ecosystem
2

SCRUM 103
The Agile Ecosystem
PRODUCT
OWNER
BURN-DOWN
CHART
PLANNING
POKER
SCRUM
TEAM
USER STORIES
SPRINT BACKLOG
DEFINITION OF DONE
DELIVERY
LEAD
STORY
BOARDS
PRODUCT
BACKLOG
ENVIRONMENTAL
MARKET FORCES
CEREMONIES PRACTICES
SELF-
ORGANISATION
BEHAVIOURS
IMPEDIMENTS
& RISK

SCRUM 103
PRODUCT
OWNER
ENVIRONMENTAL
MARKET FORCES
PRODUCT
BACKLOG
DELIVERY
LEAD
SPRINT
BACKLOG
PLANNING
POKER
STORY
BOARDS
BURN-DOWN
CHART
PLANNING
PART 1
PLANNING
PART 2
DAILY
STAND-UP
RETROSPECTIVE
DEFINITION OF
DONE
SHOWCASE
THE SPRINT
GROOMING
PRE-DELIVERY
STAKEHOLDERS
SCRUM
TEAM

SCRUM 103
WHY WHAT DELIVERY
• Customer needs
understood
• Strategic alignment
• Initial scope defined
• Architecture assessment
• Risk and security
assessment
• Business value
assessment
• Indicative size estimate
• Identify stakeholders
• Feature scope defined
• Feature backlog
prioritised and MVP
• Feature t-shirt sized
• High-level solution design
• High level user interface/
design
• Release plan (Feature
level)
• High-level people
assignments and
resourcing
• Business Case
• Solution architecture
• Ready-for-work features
• Delivery plan

SCRUM 103
Scrum: Pre-Delivery
3

SCRUM 103
Scrum: Pre-Delivery - The People
3a

SCRUM 103
Product Owner
• someone from the business
• understands the market that the product
will compete in – and any other relevant
environmental factors
• maximises the value that is added to the
product
• herds the stakeholder cats
• one person – not a committee

SCRUM 103
Scrum Master
• ensures that Agile is understood and
practiced
• responsible for the technical delivery of the
Scrum team
• facilitates the removal of impediments
• helps maximise the value created by the
Scrum team
• may work across multiple Scrum teams
simultaneously

SCRUM 103
Scrum Team
• people who do the actual work
• highly accountable and committed
• stable for 6 – 12 months to build and
preserve high performance
• self-organising
• collaborative
• cross-functional

SCRUM 103
Self-Organisation
What do we mean?
self- 
tasking
self- 
managing
self- 
organising
self- 
selecting
self- 
guiding
degree of 
autonomy
task design
delivery design
intra-team design
product context
team design
org’n.context
org’n design
scope
business context

SCRUM 103
Game
Goal: Each employee is to take 40 steps
without bumping into any other employee.
Constraints:
• Each employee may take one step in a
straight line, OR
• Turn 90 degrees left; OR
• Turn 90 degrees right
• Employees may only take one of the above
three actions when the managers tell them to.

SCRUM 103
Redux
Goal: Each employee is to take 40 steps
without bumping into any other employee.
Constraints:
• Each employee may take one step in a
straight line, OR
• Turn 90 degrees left; OR
• Turn 90 degrees right
• Employees may only take one of the above
three actions when the managers tell them to.

SCRUM 103
Chickens and Pigs

SCRUM 103
The Chicken and the Pig
A chicken and a pig are hanging out on a farm.
The chicken says: "Hey, Pig. We should open a restaurant!"
The pig replies: "Hmm, maybe. What would we call it?"
The chicken says: "How about ‘Ham-n-Eggs’?"
The pig thinks for a moment and says:
"No, thanks. You'd be involved but I'd be committed!"

SCRUM 103
The Chicken and the Pig
The moral:
Chickens are involved
But pigs are committed – full members of the
team
How it applies:
Team dynamics depend on a sense of belonging
Make team membership binary – in or out
Set expectations for pigs and chickens

SCRUM 103
Scrum: Pre-Delivery - The Work
3

SCRUM 103
WORKSHOPS
User Story
• basic unit of functionality
• adds value to the product
• vertical slice through the product
• summarised as:
• “As a <type of user> I want <some goal> 
so that <some reason>”
• has acceptance criteria
• can be used to capture non-functional requirements
• can be a spike
• may include wireframes, solution details etc.
ACCEPTANCE
CRITERIA
FLOWS – SCREEN,
DATA, LOGIC, ET AL.
ARCHITECTURE –
DATA, INFRA, ET AL.
WIREFRAMES
USER STORY
UX
ARCH
DEV OPS
RELEASE

SCRUM 103
Project
Epic
User Story
User Story Hierarchy

SCRUM 103
Product Backlog
• prioritised list of all possible user stories for the product
• managed/groomed by the Product Owner
• created during insight/inception
• higher priority user stories more detailed than lower priority
• Scrum team determines sizing/estimates of user stories
• user stories can be grouped into features
• story mapping
• Minimum Viable Product a.k.a. the MVP
• Steel Thread can be identified to reduce risk
HIGH DETAIL
• SPECIFIC
• BROKEN DOWN INTO
STORIES
• READY FOR SPRINT
MEDIUM DETAIL
• FEATURE-LEVEL
• ACTIVELY GROOMED
• RELEASE PLANNING
LOW DETAIL
• IDEAS
• FUTURE WORK
• SOME PORTFOLIO/
PIPE LINE
MANAGEMENT
STORY
#
1
STORY
N+1
STORY
N+X…

SCRUM 103
Story Mapping
MVP

SCRUM 103
MVP
Steel Thread
The set of stories required to drive
out technical risks is often not the
same as the MVP
Story Mapping

SCRUM 103
Recap
Scrum - Pre Delivery
The People - Roles
The People - Self-Organised
The People - Committed
The Work - User Stories 
The Work - User Story Mapping

SCRUM 103
Delivery
4

SCRUM 103
The Sprint
• relatively short time period (e.g. 1 to 4
weeks) in which a new working version of
the product is created by delivering user
stories
• sprint length remains constant throughout an
initiative
• factors that determine sprint length:
• change horizon
• technical cycle time

SCRUM 103
Sprint Planning Meeting
• for planning the user stories to be delivered
in a sprint
• planning is a collaborative effort by the
entire Scrum team
• sprint planning meeting is in two parts:
• what will be done
• how it will be done

SCRUM 103
Sprint Planning Meeting - Part 1
WHAT
• Product Owner presents the Product Backlog to the Scrum team
• starting from the top, the Scrum team selects the user stories it
thinks it can deliver in the next sprint
• these user stories form the sprint backlog, validated by velocity
• user stories committed to should not be easily changed

SCRUM 103
Sprint Planning Meeting - Part 2
HOW
• Scrum team does any initial solution design work needed
• Scrum team does an initial plan for delivering the sprint backlog
• user stories are estimated in more detail
• if there appears to be too much or too little work then the sprint
backlog can be renegotiated with the Product Owner
• other people can be invited to attend in order to provide domain
or technical advice

SCRUM 103
Agile Estimation
What’s this points thing?
Why not person-days? 
Function points? 
Other measures of sizing?

SCRUM 103
Air conditioner Game
Goal: Keep this room at a constant temperature of 25C
for the entire working day tomorrow.
Tasks:
1. Form a group of 4
2. Write down all the factors involved in affecting the
temperature
3. Write a plan for managing that factors throughout the
day
4. Assign people to the components of the plan
5. Present the plan

SCRUM 103
Points - modelling complexity
Points: Like the air-conditioner, points are an
operational measure of productivity, rather than a
correlating factor (like man-hours).
Operationally:
1. Measure a single, directly correlating factor of
size
2. Respond to that measure proactively
3. Proactively find ways to increase the steady-state
measure

SCRUM 103
Daily Stand-Up
• brief daily meeting (e.g. 15 minutes) for the Scrum
team to achieve clarity, energy and create visibility
• during the stand-up, each Scrum team member
covers:
• what they’ve done since the last stand-up
• what they plan to do before the next one
• any impediments that they’ve got or risks
• Scrum team monitors progress towards delivering the
sprint backlog
• Scrum team may meet after the stand-up to redesign
or re-plan the rest of the sprint’s work

SCRUM 103
Story Board

SCRUM 103
Recap
Sprint Planning
Points as a measure of size
Standups

SCRUM 103
Balance Scope vs. Schedule
SCHEDULE
SCOPE
QUALITY
• Monitor Delivery
• Re-Prioritise Scope
• Add / Remove Scope
• Predict Delivery

SCRUM 103
Sprint Burn-Down
SPRINT
SCOPE
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
PREDICTED END
DATE
IDEAL
THE SPRINT

SCRUM 103
Intra-sprint change
“Change” is just further work that needs to be done
A guide for ongoing conversations:
• does it relate to a user story on the sprint backlog?
• is it a material change?
• does it align to the sprint goal?

SCRUM 103
Sprint Burn-Down
SPRINT
SCOPE
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
COMMITABLE SPRINT
THE SPRINT
REMOVED
FROM
CURRENT
SPRINT

SCRUM 103
Recap
Balancing Scope vs Schedule
Burn-downs 
Change

SCRUM 103
Definition of Done
• complete articulation of what it
means for a user story to be done
• determines quality
• owned by the Scrum team
• can change - likely to differ
between Scrum teams
• creates alignment between
scaled/dependent teams
typical elements include:
• meets all acceptance criteria
• aligns to UX, architectural, DevOps
guidelines etc.
• any up/downstream Scrum team
interface contracts met
• design and code have been peer-
reviewed
• all automated tests pass
• documentation complete

SCRUM 103
Showcase
• product demonstration to the Product
Owner at the end of the sprint
• Scrum team answers any questions about
the new version of the product
• confirms that the user stories are “done”
• Product Owner can provide feedback and
revise the product backlog

SCRUM 103
Product Backlog Burn-Down
A
1.0
B
C
D
E
B
RELEASE 1.1 1.2 1.3
PRODUCT
BACKLOG
B
C
E
B
C
D
E
C
E
C
E E E
D
E E
C
E E E
1.3
D D D D D D

SCRUM 103
Retrospective
Kaizen Introspection
• Consider:
• what went well
• what didn’t go well
• any other ideas
• in relation to people, processes and tools including the definition of “done”
• vote on proposed improvements
• allocate the most popular improvements to Scrum team members
• held after the showcase and before the next sprint planning meeting

SCRUM 103
Recap
Definition of Done 
Showcase 
Product Backlog Burn Downs 
Retrospectives

SCRUM 103
Thank you!

SCRUM 103
Appendices
6

SCRUM 103
Protips for an effective standup
6a

SCRUM 103
Role of Standup
• Product Owner Role
• Scrum Master Role
• Team Role
• Products/Deliverables - burn down chart, stories
• Equipment - Board
• Context in wider Process
• End goal of standup

SCRUM 103
Effective vs. Not Effective
People actually want to standup
Team gets focus
Team gets clarity
Team gets energised

SCRUM 103
Effective vs. Not Effective
Focus on the baton
Improvement is enabled
Accountability for delivery
Breaks into problem solving
team afterwards

SCRUM 103
Team Norms
A standup is a “habit”. A good set
of habits helps to create a high
performing team. Here’s an
example:
Norm Bad Good

SCRUM 103
Same place &
time
Late or non-
attendance
Prompt/early to
standup (no chasing)
Attentive
behaviour
People not
listening
Effective
communication
Everybody
stands
Poor body
language
Pressure on timely
standup (not a short
standup)
No electronics
People “screen
out”
Minds and bodies
both in room together
Norm Bad Good

SCRUM 103
Pass the token
“Not my turn, so
not listening”
Active listening
User Stories
attend
“I only talk about
my things”
Focus on the baton,
not the runners
Each story is a
victory
No pressure to
push
Push for greater
delivery, accountability
for velocity
Impediment
board
No visibility of
dysfunctions
Proactive raising of
impediments, and
proactive fixing
Norm Bad Good

SCRUM 103
Team owns the
board
Working on scope not on
board; or scope on board
not worked on
The board is real-
time visibility
Higher level of
detail
Standup is not
an update
Succinct, clear
short stand ups
16th minute
Try for shortest possible
standup; or a standup
with the wrong level of
detail
Breakout
conversations occur
after standup
Prepare before
standup
No clarity
Clarity on
stories
Norm Bad Good

SCRUM 103
Kanban and Scrum
6b

SCRUM 103
Scrum & Kanban
Scrum Kanban Others
A framework of
roles and
ceremonies that
balance creation of
self-managed
teams with agility.
Scheduling system
for just in time
production
Not covered.
Encourage
research!

SCRUM 103
Scaling Scrum
6c

SCRUM 103
Portfolio
Programs
Teams
STRATEGIC
TECHNICAL
& IMPLEMENTATION
INTEGRATION, 
CO-ORDINATION 
& RELEASE
BACKLOG
high level
BACKLOG
elaboration
BACKLOG
high detail
SCRUM AND
KANBAN TEAMS
KANBAN
TEAMS
KANBAN
portfolio manager
UX, DevOps,
Automation SME
sponsors
program manager
scrum master
product owner
architects
senior stakeholders, 
incl. senior architect
release & integration
managers
Kanban
Team(s)
Scrum
Team(s)
Vision
Benefits &
Measures
Capability 
Roadmap
Strategic
Architecture
UX, DevOps,
Automation, et al.
Prioritisation &
Scheduling
Systems Architecture &
Technical Debt
Release
Planning
Development
Measurement and Continuous Improvement
…
permanent teams 
of 5-9 people:
cross-skilled, 
self-managing, 
high performing.
Large Scale Agile “LeSS”
Scaled Agile Framework
“SAFe”
Disciplined Agile Delivery
“DAD”
XSCALE
Thoughtworks Scaling

SCRUM 103
Agile Coaching
6d

SCRUM 103
Scrum Masters
Product Owners
Iteration Managers
Agile Coaches
Scrum Roles

SCRUM 103
Principles &
Philosophy Prescription
Philosophical Framework vs. Prescription
target ideal state

SCRUM 103
Principles &
Agile Coaching
target ideal state
AGILE COACHING
tailors the philosophy to 
the organisation via kaizen 
approximation

SCRUM 103
Principles &
Agile Coaching
target ideal state
AGILE COACHING
tailors the philosophy to 
the organisation via kaizen 
approximation
Far harder to extract
lean pragmatism from a
prescriptive approach

SCRUM 103
Agile Coach
A nice person with a deep knowledge of
Agile toolkits, scrum, kanban, lean

SCRUM 103
Agile Coach
There is something you should understand about
the way I work. When you need me but do not want
me, then I must stay. When you want me but no
longer need me, then I have to go. It's rather sad,
really, but there it is.
- Nanny McPhee

SCRUM 103
o
r
i
g
i
n
a
l
v
e
l
o
c
i
t
y
c
h
a
n
g
e
u
n
c
e
r
t
a
i
n
t
y
m
a
k
e
-
o
r
-
b
r
e
a
k
p
o
i
n
t
p
e
a
k
e
n
t
h
u
s
i
a
s
m
“
t
h
e
m
o
m
e
n
t
o
f
c
l
a
r
i
t
y
”
p
e
r
f
o
r
m
i
n
g
s
e
l
f
-
d
i
a
g
n
o
s
i
n
g
s
e
l
f
-
o
r
g
a
n
i
s
i
n
g
sprints @ 
fine scale
velocity x
enthusiasm x
productivity
2-6 sprints 8-20 sprints
1-2 sprints
c
h
a
n
g
e
s
h
o
c
k
s
c
r
u
m
s
t
a
r
t
s
c
h
a
n
g
e
w
e
a
r
i
n
e
s
s
Short term
Agile Adoption

SCRUM 103
c
h
a
n
g
e
w
e
a
r
i
n
e
s
s
p
e
r
f
o
r
m
i
n
g
s
e
l
f
-
o
r
g
a
n
i
s
i
n
g
sprints @ 
fine scale
velocity x
enthusiasm x
productivity
2-6 sprints 8-20 sprints
1-2 sprints
c
h
a
n
g
e
s
h
o
c
k
m
a
k
e
/
b
r
e
a
k
+
c
l
a
r
i
t
y
Short term
Agile Adoption
With Agile Coach

SCRUM 103
perception of maximum performance
m
a
t
u
r
e
s
c
r
u
m
i
n
c
r
e
m
e
n
t
a
l
i
m
p
r
o
v
e
m
e
n
t
s
a
s
y
m
p
t
o
t
i
c
a
l
l
y
a
p
p
r
o
a
c
h
m
a
x
i
m
a
l
p
e
r
f
o
r
m
a
n
c
e
velocity x
enthusiasm x
productivity
sprints @ 
long scale
40+ sprints
20+ sprints
Long term
Agile Adoption

SCRUM 103
perception of maximum performance
r
e
-
n
o
r
m
i
n
g
h
i
g
h
p
e
r
f
o
r
m
i
n
g
t
e
a
m
c
o
n
t
i
n
u
a
l
l
y
r
e
s
e
t
p
e
r
f
o
r
m
a
n
c
e
e
x
p
e
c
t
a
t
i
o
n
s
sprints @ 
long scale
s
i
g
n
i
fi
c
a
n
t
t
r
y
-
a
n
d
-
s
e
e
“
p
r
o
d
u
c
t
i
v
i
t
y
h
a
c
k
i
n
g
”
velocity x
enthusiasm
40+ sprints
20+ sprints
Long term
Agile Adoption
With Agile Coach, effective
support from management and
emergence of a self-organised,
high-performing team
*240% increase in productivity **400% increase

SCRUM 103
High Performing Teams
6e

SCRUM 103
TEAM PERFORMANCE
TEAM
TO
PERFORM
1 2 3 4 5 6 7 8 9 10 11 12 13 TIME
FORM STORM NORM PERFORM
• NOT ALL TEAMS
ARE EQUAL
• TEAMS REQUIRE
TIME TO PERFORM
• TEAMS SHOULD
PERIODICALLY
INSPECT
PERFORMANCE
AND FIND WAYS
TO IMPROVE
• EVEN GIVEN THE
ABOVE, TEAMS
STILL MAY NOT
PERFORM

SCRUM 103
TRADITIONAL RESOURCE MANAGEMENT
TEAM
TO
PERFORM
PROJECT 1 PROJECT 2 PROJECT 3
• HAVE DIFFERENT
PEOPLE
• RE-LEARN TEAM
NORMS
• STARTS WITH ZERO
PERFORMANCE
BEHAVIOUR
• PERFORMS BASED
ON SCOPE
CADENCE RATHER
AND
PERFORMANCE
CADENCE,
CREATING A
“HOCKEY STICK
CRUNCH”
CONSTANTLY
REFORMING
TEAMS
PROJECT 3
TEAMS ARE NOT ‘RESOURCES’. DESIGN FOR TEAMS, NOT FOR SCOPE

SCRUM 103
CONSTANTLY RE-REFORMING TEAMS: PORTFOLIO VIEW
WATERFALL
PORTFOLIO
PROJECT 1 PROJECT 2 PROJECT 3 PROJECT 4
• NOT ALL TEAMS
ARE EQUAL
• TEAMS REQUIRE
TIME TO PERFORM
• EVEN GIVEN THE
ABOVE, TEAMS
STILL MAY NOT
PERFORM
UNPREDICTABLE
PRODUCTIVITY
ACROSS
PORTFOLIO

SCRUM 103
WHY PRESERVE PERFORMANCE?
TEAM
PERFORMANCE
SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 6
SPRINT 4 SPRINT 5
HIGH
PERFORMANCE
TEAM
MEDIUM
PERFORMANCE
TEAM
POOR TEAM
~240%
greater

SCRUM 103
www.industrieit.com
KEEPING TEAMS TOGETHER
TEAM
PERFORMANCE
SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 6
SPRINT 4 SPRINT 5
TEAM

SCRUM 103
www.industrieit.com
FIXED TEAMS, INDIVIDUAL ROTATIONS
TEAM A
TEAM B
TEAM C
TEAM D
JUL
JAN
FEB
OCT
Rotate individuals occasionally for
personal and professional growth

SCRUM 103
Traditional and Agile Comparison
6f

SCRUM 103
REQUIREMENTS
TRADITIONAL AND AGILE COMPARISON
DESIGN BUILD TEST RELEASE
INSIGHT INCEPTION
SPRINTS
AGILE
METHODOLOGY
TRADITIONAL
METHODOLOGY

SCRUM 103
REQUIREMENTS
DELIVERY RISK
DESIGN BUILD TEST RELEASE
INSIGHT INCEPTION
SPRINTS
AGILE
TRADITIONAL
HIGH
TIME

SCRUM 103
RETURN ON INVESTMENT
REQUIREMENTS DESIGN BUILD TEST RELEASE
INSIGHT INCEPTION SPRINTS
HIGH
TIME
AGILE
TRADITIONAL
TRAD AGILE
YEAR 1 0% 80%
YEAR 2 72% 210%
YEAR 3 130% 264%
PAYBACK 30 14
NPV $663,287 $2,271,181

SCRUM 103
USABLE PRODUCT
INSIGHT INCEPTION
SPRINTS
HIGH
TIME
AGILE
TRADITIONAL

SCRUM 103
TRADITIONAL ARCHITECTURE
HIGH
TIME
CLARITY
INTEGRITY

SCRUM 103
AGILE ARCHITECTURE
HIGH
TIME
CLARITY
INTEGRITY
INSIGHT INCEPTION
SPRINTS
CLARITY
INTEGRITY
?

SCRUM 103
CODE QUALITY
HIGH
TIME
INSIGHT INCEPTION
SPRINTS
?
ZERO DEFECTS
AGILE
TRADITIONAL

SCRUM 103
Acceptance Criteria
6g

SCRUM 103
Why User Stories + Acceptance Criteria?
Documentation debt, 
source of defects,
wasted development effort
What was 
intended
What was 
coded
What was 
tested
Wasted 
Testing 
Effort
Over-documentation, 
missed requirements,
source of scope creep
Because the usual documentation processes produce this:

SCRUM 103
Documentation
code
Development
Sprint Planning
Smoke Testing
Test Validation
Acceptance Testing
Acceptance Criteria/ 
Test Approach
Product
Management
Portfolio 
Management
Usage
Executive Stakeholders + End Users
Product Owners + Product Stakeholders
Developers
Functional Testing
Product Owners
Scrum Team
Business Cases (Backlog Epics)
Backlog + Wiki Structure
Sprint Backlog + 
Wiki User Stories
User Story: 
Testing Sections
User Story: 
Technical Sections
User Story: 
Delivery Decision Log
User Story > JIRA link: 
Known Bugs/Issues
Update Sprint User Stories > 
System Documentation
System Documentation: User Guides
Requests for changes, new scope, etc.
Documentation
TRADITIONAL DOCUMENTATION LIFECYCLE
code

SCRUM 103
Development
Smoke Testing
(against AC)
Test Validation
(against AC)
Acceptance Testing
(against AC)
Portfolio 
Management
Usage
Executive Stakeholders + End Users
Product Owners + Product Stakeholders
Developers
Functional Testing
(against AC)
Product Owners
Scrum Team
Business Cases (Backlog Epics)
Backlog + Wiki Structure
Sprint Backlog + 
Wiki User Stories
User Story: 
Testing Sections
User Story: 
Technical Sections
User Story: 
Delivery Decision Log
User Story > JIRA link: 
Known Bugs/Issues
Update Sprint User Stories > 
System Documentation
System Documentation: User Guides
Requests for changes, new scope, etc.
code
IDEAL DOCUMENTATION LIFECYCLE
User Stories
User Stories
Acceptance Criteria
code
Sprint Planning
(detailed US + some AC)
Acceptance Criteria
Product
Management
(high level US)

SCRUM 103
Intention = Code = Test
Microsoft 
“Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.”
Google 
“Pre-established standards or requirements a product or project must meet.”
Federate the
source of truth
Federate the
source of truth
ACCEPTANCE CRITERIA

IIT Academy: Scrum 103

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to IIT Academy: Scrum 103 (20)

Recently uploaded (20)

IIT Academy: Scrum 103