Scrum training

The Scrum Framework
Christian Miles - www.AgileAtWork.co.uk

Hello!I’m Christian Miles
You can find out more at:
www.christianmiles.com
www.agileatwork.co.uk
www.linkedin.christianmiles.com

▣ I have over 20 years experience in the software industry -
including development, development management,
project management, teaching and publications
▣ I’ve worked in Agile teams as a developer and Scrum Master
▣ I’ve coached multiple agile teams and advised many
companies on the process of adopting an Agile mindset
▣ I’ve implemented Scrum, Kanban and Scrumban
▣ This guide is a quick intro to Scrum… It’s not a definitive
guide and in places I’ve altered it to reflect what I’ve found
works best… In my opinion!
A little about me

▣ Created in the early 90’s and first published in 1995
□ Ken Schwaber
□ Jeff Sutherland
▣ In 2001, Jeff and Ken were amongst the software
development leaders who created the Agile Manifesto
▣ Scrum has been implemented in many areas not just
software development - including marketing, media,
engineering and education
▣ Scrum is just one Framework for ‘being agile’ but probably
the most famous
A brief history of Scrum

Traditional vs Agile Product
Management - Discuss
Responsibility Traditional Agile
Understand customer needs Up front and discontinuous Constant interaction
Document requirements Fully elaborated Coarsely documented
Scheduling Plan distant, one-time delivery Continuous near-term
roadmap
Prioritise requirements Not at all! (Discuss?) Every iteration
Validate requirements NA - QA? UAT? Accept every iteration
Manage change Prohibit change - Make it
costly
Adapt and adjust at every
iteration
Assess Status Milestone/Phase gates Working code at every
iteration
Assess likelihood of release
date
Crystal ball? Developers
word?
Reviewed at each
iteration/manage scope

The 4 values of Agile
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.

Focus
Because we focus on only a few things at a time, we work well
together and produce excellent work. We deliver valuable items
sooner.
5 Core values of Scrum - Focus

Courage
Because we work as a team, we feel supported and have more
resources at our disposal. This gives us the courage to undertake
greater challenges.
5 Core values of Scrum - Courage

Openness
As we work together, we express how we're doing, what's in our
way, and our concerns so they can be addressed.
5 Core values of Scrum - Openness

Commitment
Because we have greater control over our own destiny, we are
more committed to success.
5 Core values of Scrum - Commitment

Respect
As we work together, sharing successes and failures, we come to
respect each other and to help each other become worthy of
respect.
5 Core values of Scrum - Respect

The Scrum Framework
▣ The Scrum Framework
▣ Roles
▣ Ceremonies (Meetings)
▣ Artifacts
▣ What Scrum doesn’t cover

The Scrum Process
▣ Release Planning
▣ Program Backlog (Not really mentioned in
Scrum - But important in scaling context!)
▣ Product Backlog
▣ Sprint Backlog
▣ The Sprint
▣ The review AKA Demo
▣ Potentially Shippable product increment

The Scrum Process

The Sprint
▣ AKA as an Iteration
▣ Deliver a potentially shippable incremental
product
▣ No Change is allowed which would disrupt the
Sprint Goal
▣ The scope may be clarified and re-negotiated
as more is learned - Product owner can not
force changes on team

The Sprint
▣ Team remains the same
▣ Quality does not decrease to hit deadlines
▣ Sprint lengths do not change

Sprint 0
▣ Hiring the team?
▣ Hardware/Software setup?
▣ Building a continuous delivery pipeline?
▣ My advice…. Try and avoid at all costs!

Hardening Sprints
▣ An optional approach!
▣ Its a Sprint left empty at the release planning
stage
▣ Sometimes used to move work from ‘Done’ to
‘Done Done’
▣ IS NOT CONTINGENCY
▣ My advice - Try and avoid… but they are
perhaps a reality with Scrum at scale!

Cancelling a Sprint
▣ Almost never happens!
▣ Only the Product Owner can cancel a Sprint
▣ Usually only occurs if the Sprint Goal becomes
obsolete….
▣ If it does… Review, retrospective and re-plan

Who’s Listening?
▣ What's the output of a sprint?
▣ How long does a sprint last?
▣ How are changes to work handled within a
Sprint?
▣ Who can cancel a Sprint?

The Scrum Framework
▣ The Roles
□ The chicken and the pig
□ Product Owner
□ Scrum Master
□ Development Team (Everybody else)
□ Stakeholders, business, customers, managers

The Roles

The Roles
▣ Pigs (Fully Committed)
□ The Scrum team
□ The Product Owner
▣ Chickens (Merely involved)
□ Everybody else!
▣ The Scrum Master?

The Product Owner
▣ One person - not a committee
□ May represent multiple stakeholders
▣ Responsible for maintaining the Product
backlog
▣ Decides when releases are made
▣ Must have organisational respect and authority

The Product Owner - Responsibilities
▣ Maintains the Backlog
□ May delegate parts of this to the dev team.
▣ Sets the vision statement for each phase of
delivery
▣ Sets the Sprint goal - With the team
▣ Enforces the Definition of Done
▣ Ensure Development team understands the
backlogChristian Miles - www.AgileAtWork.co.uk

The Product Owner - Responsibilities
▣ Must participate in Sprint Planning
▣ Must participate in Sprint Review
▣ May participate in Daily Standup
▣ May participate in Retrospective
□ The retrospective is for the team so ensure that you
have ‘Private’ retrospectives to ensure that the
Product Owner is not interfering with being self-
organising

The Scrum Master
▣ The “Servant Leader” -
□ No authority over the team (With the exception of
enforcing Agile practices)
▣ Cannot commit to dates
▣ Is NOT accountable for team success
▣ Has a largely coaching role
▣ Is mainly responsible for holding a mirror up to
the organisation!Christian Miles - www.AgileAtWork.co.uk

The Scrum Master - Responsibilities
▣ Facilities Scrum Ceremonies
▣ Coaches the Scrum Team, Product Owner,
Stakeholders and organisation on being Agile
▣ Protects the Scrum Team
▣ Acts a change agent

The team (Everyone else)
▣ Usually Between 4 and 8 members
□ 2 Pizza rule - If you can’t feed a team with 2 pizza’s
it's too big
▣ Product Owner is NEVER part of the team
▣ Scrum Master might be… If working on Backlog
items
▣ Cross-functional, Includes testers, BA’s all
considered development

The Team - Responsibilities
▣ Self organising - No appointed leader!
□ Can you have a self organising team with a leader?
▣ Creates a potentially shippable ‘product’ each
sprint
▣ Maintains a Sprint Backlog for each Sprint
▣ Collectively commits to delivering the Sprint
Goal

Everybody else
▣ Stakeholders, Customers, Managers!

Who’s Listening?
▣ Product Owner Pig or Chicken?
▣ Is the Scrum Master a pig?
▣ Role of the Product Owner

3.
Ceremonies
(AKA as
Meetings)

Ceremonies
▣ The Planning Session
▣ The Daily Stand-up
▣ The Review
▣ The Retrospective
▣ Backlog Refinement

Planning Session - Part 1 (What & Why)
▣ Occurs at the start of every Sprint
▣ Time boxed
□ Typically 4 hours for a 2 week sprint, team of 8
▣ PO should come prepared with a Sprint Goal
□ This might be altered after discussion with the team
▣ All team members and PO attend
▣ PO Selects the stories to be worked on
▣ Development team commits to what’s

Planning Session - Part 2 (How)
▣ Team breaks stories into tasks and agrees how to
implement
▣ The PO may attend
▣ Other parties may attend
▣ The Scrum Master facilities process

The Daily Stand-up
▣ Occurs every day
▣ Time boxed - Usually 15 minutes
▣ Is NOT a status report for management
□ Can be used to report back to the Scrum Team
▣ Sets the agenda for the day
□ Try creating a day goal or selecting the most important
story to finish
▣ Should help the team achieve the Sprint Goal
□ Set by the Product Owner

The Daily Stand-up
▣ We answer 3 questions
□ What did I do yesterday?
□ What do I intend to do today?
□ What impediments or blockers do I have?

The Daily Stand-up
▣ The latest Scrum Guide suggests:
□ What did I do yesterday to help the team achieve it’s
Sprint Goal? If nothing (Major impediment)
□ What will I do today to help the team achieve it’s
Sprint Goal?
□ What issues do I have that might prevent me hitting
the Sprint Goal
▣ Make sure that blockers are recorded
▣ The Scrum Master being responsible for
resolving blockers… Is an Anti-pattern! (Discuss)

The Daily Stand-up
▣ The Scrum Master ensures that the Stand-up
happens
▣ The Stand-up is for the benefit of the team…
Not the Scrum Master… It’s NOT a status
meeting it’s a PLANNING meeting
▣ Only Dev team and PO may attend (Personally I
allow anyone to observe, or ask ‘reasonable
questions)

The Daily Stand-up
▣ Complex Issues are taken off-line
▣ Address Blockers from the day before if still
blocked
▣ Try and make the stand-up’s board focussed
▣ Don’t be afraid to experiment with the format…
The 3 questions are a start but it’s a planning
meeting designed to set focus

The Daily Stand-up
Personally…..
▣ Forget the 3 questions! They make it too much
status based - Especially what did I do
yesterday!
▣ Keep it task board based/focused and agree
what the day’s objective is
▣ Allow conversations to continue - that are
useful and helpful - But be mindful of time!

Backlog Refinement
▣ Once known as Backlog Grooming - But had a
name change in 2013!
▣ I like to hold several short sessions each Sprint
▣ The Product Backlog is the responsibility of the
PO- They add stories and sequence
▣ The PO is responsible for ensuring that the
development team understand the Backlog
▣ “Story Writing Workshops” are an excellent way to
achieve this

The Review - Not a demo!
▣ Occurs at the end of the Sprint
▣ Time boxed - Usually around 1 - 2 hours (2 Week
Sprint)
▣ Informal meeting
□ Encourage feedback and collaboration
▣ What was done in the Sprint
▣ Discuss how the Sprint went

▣ Product Owner should enforce the ‘Definition Of
Done’ for each Story
▣ Team might demo to PO
□ Often good to get the PO to do the demonstration
▣ PO determines if the Sprint Goal has been met
▣ PO Should discuss the Product Backlog and
dates
▣ Discuss what should be done next

▣ The entire team attends
▣ The PO attends
▣ Interested Stakeholders may attend
▣ The Scrum Master facilities

The Retrospective
▣ Occurs at the end of the Sprint, After the Demo
▣ Time Boxed - Between 1 and 2 hours for a 2 week
Sprint
▣ You should hold a large retrospective after each
phase/major release with all stakeholders (Where
possible)

The Retrospective
▣ How does everyone feel about the Sprint?
▣ What worked well in the last Sprint?
▣ What didn’t work well
▣ Draw up an improvement plan - Improvement
stories should go on the back log

The Retrospective
▣ Regardless of what we discover… We understand
and truly believe that everyone did the best job
that they could given what they knew at the
time, their situation, skills and abilities.
▣ Collective storytelling - Helps us learn from
shared experiences
▣ Gathering data helps us make empirical based
decisions

Who’s Listening?
▣ What's the output of the Planning Session?
▣ What’s the purpose of the retrospective?
▣ How long should the planning session last?
▣ What’s the purpose of the Daily Standup?
▣ How many parts is the planning session made
up of?

4.
Artifacts
(AKA as
Documentation)

The Scrum Framework
▣ Artifacts AKA Documentation
□ The Product Backlog
□ The Sprint Backlog
□ The Vision Statement
□ The Sprint Goal
□ The Definition of Done
□ Impediments - Or risk register
□ Burn down/up charts
□ Task Board

The Product Backlog
▣ Is the responsibility of the Product Owner to Maintain
□ However the PO may use the team to help maintain
and ‘flesh’ out stories
▣ It should be ordered with the most important stories at the
top
▣ Regular refinement (once known as grooming) is essential
and time should be set aside during every Sprint
▣ Expect around 10% of team time to be spent on backlog
refinement. (About a day for a 2 week sprint/iteration)

The Product Backlog
▣ Each PBI (Product Backlog Item) should be small enough
to complete in one Sprint (Usually 1-5 days effort, a
preference for the lesser)
▣ Each PBI should be a complete vertical slice of user
functionality
▣ Each PBI should contain acceptance criteria
□ Given, When, Then is one format
▣ ‘User Stories’ is a very common technique - But not a
prescriptive part of Scrum

The Product Backlog
▣ Is NOT a signed off document
▣ It’s a living document… Expect it change!
▣ Covers everything! Stories, enhancements, fixes,
dependencies, Investigation spikes and retrospective items!

The Sprint Backlog
▣ Deliverable of the Planning Session
▣ The Product Owner selects the most important stories to
enter the Sprint Backlog
▣ The team decides how many are committed to
▣ The development team decides how stories will be broken
down and completed

The Sprint Backlog
▣ The Development team also has the right to refuse a story
that is not well understood
□ Set an acceptance criteria for allowing a story to enter
the sprint. (Definition of Ready)

The Vision Statement
▣ Set by the Product Owner
▣ Should be set for each phase of development
▣ Ensures that everybody on the team is aware of the end
target

The Sprint Goal
▣ The Sprint Goal should be Set by the Product Owner
▣ However the development team may shape it based on
what they think can be delivered to within the Sprint
▣ It’s purpose is to set the focus in the Sprint
▣ Make sure it’s on the Task Board (Where physical) but make
it visible

The Definition of Done
▣ The team along with the PO should define the Definition of
Done
▣ Each Sprint should be judged against this definition - The
Product owner is responsible for ensuring the sprint
adheres to it
▣ Ideally ‘Done’ should mean “Done, Done”
□ It’s common to have several definitions…. ‘Done’, ‘Ready
to Release’

The Definition of Done
▣ Make sure everyone knows the definition of Done and stick
it somewhere visible - On the wall in the team’s area
▣ Definition of ready, ready to release, ready to test!
▣ Define it but don’t be tempted to over define! Just enough
is enough!

Impediments
▣ Record issues and problems that are discovered
▣ I often record these on the Task Board (Where physical) and
should be brought up in every Stand-up
▣ Create a risks board - on the wall, visible and ensure it’s
addressed every day
□ RAID log, Risks, Assumptions, Issues and Dependencies
□ Or ROAM (Resolved, Owned, Accepted, Mitigated)

Burndown/Up Charts
▣ Sprint burndown chart….. Work required to complete sprint
(Often done in hours) personally I never use burn-down
charts!!! They’ve been made famous by CSM courses and
software products! But add no real value!
▣ Release burndown chart…. Work on Product Backlog that
needs completing before release (Often done in Story
points)
▣ You also get burn-up charts… Record the effort done,

The Task Board
▣ Can be physical or virtual
▣ My personal favourite is physical wherever possible… It aids
transparency and collaboration which in turns breeds trust!
□ Less suitable for teams which are distributed!!
▣ Physical task boards are often called Information Radiators
▣ Virtual boards are known as Information Refrigerators!

Who’s Listening?
▣ Who owns the Sprint Backlog?
▣ What’s the purpose of the Sprint Goal?

Development Practice
▣ Both Agile, Scrum and Kanban don’t prescribe software
development practices
▣ Remember Scrum and Kanban are used outside of the
world of software development!
▣ XP - eXtreme Programming is often used alongside Agile
practices:
□ Paired programming
□ TDD, BDD (Given, When, Then) - Automated testing
□ Continuous integration
□ Peer review

Wider Project Management Concerns
▣ Unlike PRINCE2 (PRojects In Controlled Environments)
Scrum does not talk about project initiation, justification,
Sign-offs, Project closure
▣ It does not talk about portfolio management, governance
or quality process procedures
▣ Does not talk about how to scale
▣ Although frameworks like LeSS (Large Scale Scrum), SAFe
(Scaled Agile Framework) and DAD (Disciplined Agile
Delivery) are addressing some of those issues

What I’ve not covered
▣ Lots!
▣ Story writing
▣ Estimation and Velocity
▣ How to identify your Minimum (Marketable/Viable) Product

Thanks!
Please keep in touch
Find me at www.christianmiles.com
or https://www.linkedin.com/in/christianleemiles
To discover more about Agile….
www.agileatwork.co.uk
https://twitter.com/christianlmiles

Scrum training

More Related Content

What's hot

Similar to Scrum training

Recently uploaded

Scrum training