SlideShare a Scribd company logo
1 of 74
Scrum at Bond - Q2 2017
Today we are going to cover...
● Agile/Scrum Overview
● Sprint planning
Why are you seeing this?
● Share our standard and best practices
● Give everyone a chance to ask questions and align
What are the benefits?
● Improve our overall quality of work
● Better communication between product and
engineering teams
Agile Overview
In this section we will cover:
● What is Agile software development
● The Agile Manifesto
What is Agile?
Agile software development refers to a group of
software development methodologies based on
iterative development, where requirements and
solutions evolve through collaboration between self-
organizing cross-functional teams.
What does this mean?
Agile frameworks embody incremental, iterative
delivery (“Fail fast and learn”) of software instead of all
at once.
The Agile Manifesto
Rule 1:
Individuals and interactions over processes and tools.
The most efficient and effective method of conveying
information to and within a development team is face-
to-face conversation.
Rule 2:
Working software over comprehensive documentation.
Working software is the primary measure of progress.
Rule 3:
Customer collaboration over contract negotiation.
Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
Rule 4:
Responding to change over following a plan.
Welcome changing requirements, even late in
development. Agile processes harness change for the
customer's competitive advantage.
Agile is NOT waterfall
With agile development we do not spec the entirety of
a system, built it all, and only then put it in hands of
end users.
Types of Agile methodologies
● Scrum
● Kanban
Questions on Agile?
Scrum Overview
Not this type of Scrum
In this section we will cover:
● What is Scrum
● What are Sprints
● Scrum Roles
● Scrum Activities
We use Scrum for agile
development at Bond
What is Scrum?
Scrum is an agile framework for building products in a
series of fixed-length iterations (Sprints).
Scrum is not just a fancy acronym
Agile processes
promote sustainable
development.
The sponsors,
developers, and
users should be able
to maintain a
constant pace
indefinitely.
What is a “Sprint”?
● In Scrum, teams forecast to complete a set of
issues during a fixed time duration, known as a
sprint
● Sprints are timeboxed in that they have a fixed
start date and end date
○ Generally sprints are two, three or four weeks
long
○ At Bond a typical sprint is two weeks in length
Scrum Roles
Scrum development efforts consist of one or more
Scrum teams, each made up of three Scrum roles:
Product owner, ScrumMaster (Delivery Manager), and
the Development team.
Product Owner
Master note taker and backlog champion
● Accountable for the product
● Owns and prioritizes the Product Backlog
● Provides goals and vision
● Understands the market, users and the business in
order to make sound decisions
Key Term - Product Backlog
Using Scrum we always do the most valuable work first!
Product owner’s (with input from the rest of the Scrum
team and stakeholders) are responsible for
determining and managing the sequence of work.
This prioritized list is known as the product backlog.
ScrumMaster (Delivery Manager)
Master tasker, knows how to get stuff delivered
● Works with the Product Owner to define the
roadmap for any given product and translate this
into user stories
● Enforces process
● Prevents and remove impediments
● Tracks metrics
● Facilitates Daily Scrum
Development Team
Builders of high-quality, working software.
● Self-organizes to determine the best way to
accomplish the goal set out by the product owner
● Creates their own tasks
● Pulls stories from the Product Backlog
● Owns the sprint backlog
● Provides estimates and commitments
Scrum Activities
Scrum activities at Bond
1. Daily stand-up
2. Sprint planning
3. Sprint review
4. Retrospective
Questions on Scrum?
Daily Stand-up
In this section we will cover:
● Overview of daily standup
● Format
● Best practices
What is the daily stand-up?
Meetings are typically held in the same location and at
the same time each day. Ideally, a daily scrum
meeting is held in the morning, as it helps set the
context for the coming day's work.
These scrum meetings are strictly time-boxed to 15
minutes. This keeps the discussion brisk but relevant.
How we relentlessly prioritize the day’s work
Daily stand-up - format
All team members are required to attend scrum
meetings. Each team member answers the following
three questions:
1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way?
Daily stand-up - best practices
● The daily stand-up meeting is not used as a
problem-solving or issue resolution meeting.
○ Issues that are raised are taken offline and
usually dealt with by the relevant subgroup
immediately after the meeting.
● Any impediments that are raised in the scrum
meeting become the delivery manager’s
responsibility to resolve as quickly as possible.
Sprint Planning
In this section we will cover:
● Overview of sprint planning
● What is “Ready” for work
● Acceptance criteria
● Story points
● Planning poker
● Velocity
What is Sprint planning?
During the sprint planning meeting, the product owner
describes the highest priority features to the team.
The team asks enough questions that they can turn a
high-level user story of the product backlog into the
more detailed tasks of the sprint backlog.
Defining the "What" and "How" the Scrum team will deliver
Sprint planning - general rules
● Attended by the product owner, scrum master, and
scrum team for the upcoming sprint
○ In addition to development team, could
potentially include design/UX resources
● Held for 1-2 hours at the beginning of a sprint
● Important to book a conference room and allot
proper time (1 hour for every week of sprint to
plan)
Purpose of sprint planning
Sets up the entire team for success throughout the sprint.
During sprint planning
we define:
1. The sprint goal
2. The sprint backlog
Key Term - Sprint Goal
A sprint goal is a short, one- or two-sentence,
description of what the team plans to achieve during
the sprint.
It is written collaboratively by the team and the product
owner.
Key Term - Sprint Backlog
The sprint backlog is a list of the product backlog
items the team commits to delivering plus the list of
tasks necessary to delivering those product backlog
items.
It’s the product owner’s job to make sure all items
being discussed are “ready”.
What makes a backlog item “Ready”?
"Ready" items should be clear, concise, and most importantly, actionable.
● "Ready" means that stories must be immediately
actionable
● The Team must be able to determine what needs
to be done and the amount of work required to
complete the backlog item
● The Team must understand the acceptance criteria
and what tests will be performed to demonstrate
that the story is complete
Acceptance Criteria (A/C)
Sets clear expectation as to when a team should consider something done.
● Product owners are responsible for creating A/C
and validating whether work is complete
● It helps the team to break down the user stories
into task(s)
● Unique for each backlog item
● A ticket without criteria, should not be considered
"ready"
Bond format for A/C
I will consider this done when…
● -Action a yields x result
● -Action b yields y result
● -Action c yields z result
Typically there should be at least 4, no more than 12
actions described.
A/C differs from the “Definition of Done”
A/C is unique to every backlog item.
The Definition of Done (DoD) is a clear and concise
list of requirements that the user story must satisfy for
the team to call it complete. The DoD must apply to all
items in the backlog.
Definition of done at Bond
Examples at Bond:
● Passed QA and code review
● Unit test written
● Seen by and approved by the Product Owner
Acceptance Criteria Examples
The Good
“As a Bond employee, I want a dropdown from live search with corresponding
fields.”
Why is that a “good” example?
● Clear A/C with fringe rules outlined for the feature
● Expectation for how feature should behave once
user interacts
● Limits for how feature should be implemented are
clear
● Visual or prototype attached to the ticket
The Bad
“As a Bond employee, I want to create an invoice for a user.”
Why is that a “bad” example?
● Overly complex for a single item, thus A/C is more
work then could be completed in a single sprint
○ This should have been split into multiple tickets
○ Every single editable field could have been
individual ticket
● Specific visual spec is not attached to ticket
● Not all work is actionable at moment
The Ugly
“As a Bond employee, I want to see success or failure on my interactions with
Skyfall.”
Exercise Break
Draw me a house
Draw me a house
I will consider this done when:
● There is a door on the lower floor in the middle of the house
● On each side of the door there is a window
● On the upper floor, there are three windows evenly spaced across
the house
● The house has a pitched roof.
● There is a chimney
● The house has a garage
● The house has a fence around a garden
● The fence has a gate
● There is a path from the door of the house to the gate
● The garden has a tree
Questions on sprint planning,
definition of “ready”, or
acceptance criteria?
Story points and estimation
Now that our backlog item’s are ready it’s time to
estimate story points.
Story points are a measure of the relative size of a
backlog item, taking into account factors such as
complexity and physical size.
We use planning poker for estimation
● The goal of planning
poker is to gather
consensus among
team members
● The work we agree to
do, is the work we
agree to complete
How planning poker works
1. The product owner describes each item to the
team before they estimate it
2. Product owner answers questions regarding
functionality to make sure end goal is clear
3. Any member of team who will be contributing to
completion votes with planning poker card
4. The majority wins the vote, but for huge
discrepancies this is a good time to have dialogue
so any potential unforeseen issues are brought up.
Guidelines for story points
● Issue that is understood and can be done and
deployed in under an hour ≤ 3
● Issue requiring a bit of understanding but can be
done in a few hours = 5
● Issue requiring research and thought before
implementation = 8
● Issue requiring potentially multiple days and efforts
to accomplish = 13
○ Max hours for a 13 point ticket = 16 hours
How much is too much?
Using “Velocity” to predict a team’s capacity for work.
At the end of each iteration (sprint), the team adds up
effort estimates associated with user stories that were
completed during that iteration. This total is called
velocity.
Past velocity is a great indicator for how many story
points to include in a sprint.
Planned vs. actual velocity
Planned velocity is the total number of story points
that the team has committed to for the sprint.
Actual velocity is the total number of story points the
team completes during the sprint.
Expect the unexpected
It’s the product owner’s role to prevent the the team from over-committing.
Other factors that
influence velocity:
● Holidays
● Time off for
members of team
● Internet/heat
outages
Time-boxing sprints is absolutely critical
The fixed start and end dates are a commitment
between team members that you will take on and
complete X amount of work, and in the allotted period
of time.
If we allow sprints to run past the timebox it ruins the
ability to accurately predict the future amount of work
a team can accomplish (velocity).
What happens when you don’t timebox?
The perils of not time-boxing
● The 200 point sprint was only possible because we
did not adhere to the timebox rules
● We began enforcing timeboxed sprints and at first
it was ugly. A sprint with only half the points
completed
● With timeboxing, preparation is much more
thorough before starting work, thus what we
“commit to complete,” we expect to deliver
Format for Sprints at Bond
How to use Jira for planning and starting sprints.
● Sprint Goal
● Sprint Name
○ Year/Month/Date
started
○ This makes it easy to
look at prior sprints
What have we learned today?
● What is agile development
○ The agile manifesto
● What is Scrum
○ Roles and activities
● Daily stand-up
● Sprint planning
○ How to plan and start a sprint
○ What is “Ready” for work
○ Acceptance criteria
○ Story points
○ Planning poker
○ Velocity
Questions?
Further resources
● Daily stand-ups
● Sprint planning
● Sprint reviews
● Sprint retrospective
● Jira agile guidelines

More Related Content

What's hot

What's hot (20)

Agile scrum fundamentals
Agile scrum fundamentalsAgile scrum fundamentals
Agile scrum fundamentals
 
Scrum an Agile Methodology
Scrum an Agile MethodologyScrum an Agile Methodology
Scrum an Agile Methodology
 
Short introduction to Agile Scrum
Short introduction to Agile ScrumShort introduction to Agile Scrum
Short introduction to Agile Scrum
 
Scrum basics
Scrum basicsScrum basics
Scrum basics
 
Agile Course
Agile CourseAgile Course
Agile Course
 
The Essence of Sprint Planning : Presented by Sprint Planning
The Essence of Sprint Planning : Presented by Sprint PlanningThe Essence of Sprint Planning : Presented by Sprint Planning
The Essence of Sprint Planning : Presented by Sprint Planning
 
Software Design principales
Software Design principalesSoftware Design principales
Software Design principales
 
Agile and Scrum - GB
Agile and Scrum - GBAgile and Scrum - GB
Agile and Scrum - GB
 
Agile course Part 1
Agile course Part 1Agile course Part 1
Agile course Part 1
 
Scrum ceromonies
Scrum ceromoniesScrum ceromonies
Scrum ceromonies
 
Agile Introduction - Scrum Framework
Agile Introduction - Scrum FrameworkAgile Introduction - Scrum Framework
Agile Introduction - Scrum Framework
 
Agile Network India | Guesstimating the timeline for backlog items | Amit Med...
Agile Network India | Guesstimating the timeline for backlog items | Amit Med...Agile Network India | Guesstimating the timeline for backlog items | Amit Med...
Agile Network India | Guesstimating the timeline for backlog items | Amit Med...
 
Agile Network India | Guesstimating the timeline for backlog items
Agile Network India | Guesstimating the timeline for backlog itemsAgile Network India | Guesstimating the timeline for backlog items
Agile Network India | Guesstimating the timeline for backlog items
 
Agile Project Management
Agile Project ManagementAgile Project Management
Agile Project Management
 
OverView to PMP
OverView to PMPOverView to PMP
OverView to PMP
 
The Scrum Model
The Scrum ModelThe Scrum Model
The Scrum Model
 
Scrum and agile principles
Scrum and agile principles Scrum and agile principles
Scrum and agile principles
 
Agile philosophy
Agile philosophyAgile philosophy
Agile philosophy
 
Agile Scrum
Agile ScrumAgile Scrum
Agile Scrum
 
Overview of Agile methodology & Scrum
Overview of Agile methodology & ScrumOverview of Agile methodology & Scrum
Overview of Agile methodology & Scrum
 

Similar to Agile and Scrum Overview for PMs, Designers and Developers

Scrum Intro for E-works
Scrum Intro for E-worksScrum Intro for E-works
Scrum Intro for E-works
Nora Papazyan
 

Similar to Agile and Scrum Overview for PMs, Designers and Developers (20)

Agile scrum training
Agile scrum trainingAgile scrum training
Agile scrum training
 
Agile Methodologies by TechDesti
Agile Methodologies by TechDestiAgile Methodologies by TechDesti
Agile Methodologies by TechDesti
 
Fundamental of Scrum
Fundamental of ScrumFundamental of Scrum
Fundamental of Scrum
 
Introduction To Agile
Introduction To AgileIntroduction To Agile
Introduction To Agile
 
Scrum Intro for E-works
Scrum Intro for E-worksScrum Intro for E-works
Scrum Intro for E-works
 
Agile Methodology
Agile MethodologyAgile Methodology
Agile Methodology
 
Scrum Method
Scrum MethodScrum Method
Scrum Method
 
Agile_basics
Agile_basicsAgile_basics
Agile_basics
 
Agile scrum
Agile scrumAgile scrum
Agile scrum
 
Scrum and Devops - Workshop & Handson
Scrum and Devops - Workshop & HandsonScrum and Devops - Workshop & Handson
Scrum and Devops - Workshop & Handson
 
professional scrum master
professional scrum master professional scrum master
professional scrum master
 
Scrum, A Brief Introduction
Scrum, A Brief IntroductionScrum, A Brief Introduction
Scrum, A Brief Introduction
 
Scrum
ScrumScrum
Scrum
 
PMI-ACP: Domain I - Agile Principles and Mindset_v1.0
PMI-ACP: Domain I - Agile Principles and Mindset_v1.0PMI-ACP: Domain I - Agile Principles and Mindset_v1.0
PMI-ACP: Domain I - Agile Principles and Mindset_v1.0
 
agile-and-scrum-methodology.pptx
agile-and-scrum-methodology.pptxagile-and-scrum-methodology.pptx
agile-and-scrum-methodology.pptx
 
Scrum Overview
Scrum OverviewScrum Overview
Scrum Overview
 
Practicing Agile through Scrum
Practicing Agile through ScrumPracticing Agile through Scrum
Practicing Agile through Scrum
 
Content production using scrum
Content production using scrumContent production using scrum
Content production using scrum
 
Agile practices for management
Agile practices for managementAgile practices for management
Agile practices for management
 
Agile (Scrum)
Agile (Scrum)Agile (Scrum)
Agile (Scrum)
 

Recently uploaded

“Iamnobody89757” Understanding the Mysterious of Digital Identity.pdf
“Iamnobody89757” Understanding the Mysterious of Digital Identity.pdf“Iamnobody89757” Understanding the Mysterious of Digital Identity.pdf
“Iamnobody89757” Understanding the Mysterious of Digital Identity.pdf
Muhammad Subhan
 
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
FIDO Alliance
 
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
panagenda
 

Recently uploaded (20)

How to Check GPS Location with a Live Tracker in Pakistan
How to Check GPS Location with a Live Tracker in PakistanHow to Check GPS Location with a Live Tracker in Pakistan
How to Check GPS Location with a Live Tracker in Pakistan
 
State of the Smart Building Startup Landscape 2024!
State of the Smart Building Startup Landscape 2024!State of the Smart Building Startup Landscape 2024!
State of the Smart Building Startup Landscape 2024!
 
Cyber Insurance - RalphGilot - Embry-Riddle Aeronautical University.pptx
Cyber Insurance - RalphGilot - Embry-Riddle Aeronautical University.pptxCyber Insurance - RalphGilot - Embry-Riddle Aeronautical University.pptx
Cyber Insurance - RalphGilot - Embry-Riddle Aeronautical University.pptx
 
Event-Driven Architecture Masterclass: Challenges in Stream Processing
Event-Driven Architecture Masterclass: Challenges in Stream ProcessingEvent-Driven Architecture Masterclass: Challenges in Stream Processing
Event-Driven Architecture Masterclass: Challenges in Stream Processing
 
Introduction to use of FHIR Documents in ABDM
Introduction to use of FHIR Documents in ABDMIntroduction to use of FHIR Documents in ABDM
Introduction to use of FHIR Documents in ABDM
 
Microsoft CSP Briefing Pre-Engagement - Questionnaire
Microsoft CSP Briefing Pre-Engagement - QuestionnaireMicrosoft CSP Briefing Pre-Engagement - Questionnaire
Microsoft CSP Briefing Pre-Engagement - Questionnaire
 
The Ultimate Prompt Engineering Guide for Generative AI: Get the Most Out of ...
The Ultimate Prompt Engineering Guide for Generative AI: Get the Most Out of ...The Ultimate Prompt Engineering Guide for Generative AI: Get the Most Out of ...
The Ultimate Prompt Engineering Guide for Generative AI: Get the Most Out of ...
 
Continuing Bonds Through AI: A Hermeneutic Reflection on Thanabots
Continuing Bonds Through AI: A Hermeneutic Reflection on ThanabotsContinuing Bonds Through AI: A Hermeneutic Reflection on Thanabots
Continuing Bonds Through AI: A Hermeneutic Reflection on Thanabots
 
AI in Action: Real World Use Cases by Anitaraj
AI in Action: Real World Use Cases by AnitarajAI in Action: Real World Use Cases by Anitaraj
AI in Action: Real World Use Cases by Anitaraj
 
Navigating the Large Language Model choices_Ravi Daparthi
Navigating the Large Language Model choices_Ravi DaparthiNavigating the Large Language Model choices_Ravi Daparthi
Navigating the Large Language Model choices_Ravi Daparthi
 
JohnPollard-hybrid-app-RailsConf2024.pptx
JohnPollard-hybrid-app-RailsConf2024.pptxJohnPollard-hybrid-app-RailsConf2024.pptx
JohnPollard-hybrid-app-RailsConf2024.pptx
 
“Iamnobody89757” Understanding the Mysterious of Digital Identity.pdf
“Iamnobody89757” Understanding the Mysterious of Digital Identity.pdf“Iamnobody89757” Understanding the Mysterious of Digital Identity.pdf
“Iamnobody89757” Understanding the Mysterious of Digital Identity.pdf
 
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
 
2024 May Patch Tuesday
2024 May Patch Tuesday2024 May Patch Tuesday
2024 May Patch Tuesday
 
Design and Development of a Provenance Capture Platform for Data Science
Design and Development of a Provenance Capture Platform for Data ScienceDesign and Development of a Provenance Capture Platform for Data Science
Design and Development of a Provenance Capture Platform for Data Science
 
How we scaled to 80K users by doing nothing!.pdf
How we scaled to 80K users by doing nothing!.pdfHow we scaled to 80K users by doing nothing!.pdf
How we scaled to 80K users by doing nothing!.pdf
 
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
 
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
Easier, Faster, and More Powerful – Alles Neu macht der Mai -Wir durchleuchte...
 
How to Check CNIC Information Online with Pakdata cf
How to Check CNIC Information Online with Pakdata cfHow to Check CNIC Information Online with Pakdata cf
How to Check CNIC Information Online with Pakdata cf
 
Event-Driven Architecture Masterclass: Engineering a Robust, High-performance...
Event-Driven Architecture Masterclass: Engineering a Robust, High-performance...Event-Driven Architecture Masterclass: Engineering a Robust, High-performance...
Event-Driven Architecture Masterclass: Engineering a Robust, High-performance...
 

Agile and Scrum Overview for PMs, Designers and Developers

  • 1. Scrum at Bond - Q2 2017
  • 2. Today we are going to cover... ● Agile/Scrum Overview ● Sprint planning
  • 3. Why are you seeing this? ● Share our standard and best practices ● Give everyone a chance to ask questions and align
  • 4. What are the benefits? ● Improve our overall quality of work ● Better communication between product and engineering teams
  • 6. In this section we will cover: ● What is Agile software development ● The Agile Manifesto
  • 7. What is Agile? Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self- organizing cross-functional teams.
  • 8. What does this mean? Agile frameworks embody incremental, iterative delivery (“Fail fast and learn”) of software instead of all at once.
  • 10. Rule 1: Individuals and interactions over processes and tools. The most efficient and effective method of conveying information to and within a development team is face- to-face conversation.
  • 11. Rule 2: Working software over comprehensive documentation. Working software is the primary measure of progress.
  • 12. Rule 3: Customer collaboration over contract negotiation. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • 13. Rule 4: Responding to change over following a plan. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  • 14. Agile is NOT waterfall With agile development we do not spec the entirety of a system, built it all, and only then put it in hands of end users.
  • 15. Types of Agile methodologies ● Scrum ● Kanban
  • 18. Not this type of Scrum
  • 19. In this section we will cover: ● What is Scrum ● What are Sprints ● Scrum Roles ● Scrum Activities
  • 20. We use Scrum for agile development at Bond
  • 21. What is Scrum? Scrum is an agile framework for building products in a series of fixed-length iterations (Sprints).
  • 22. Scrum is not just a fancy acronym Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • 23. What is a “Sprint”? ● In Scrum, teams forecast to complete a set of issues during a fixed time duration, known as a sprint ● Sprints are timeboxed in that they have a fixed start date and end date ○ Generally sprints are two, three or four weeks long ○ At Bond a typical sprint is two weeks in length
  • 24. Scrum Roles Scrum development efforts consist of one or more Scrum teams, each made up of three Scrum roles: Product owner, ScrumMaster (Delivery Manager), and the Development team.
  • 25. Product Owner Master note taker and backlog champion ● Accountable for the product ● Owns and prioritizes the Product Backlog ● Provides goals and vision ● Understands the market, users and the business in order to make sound decisions
  • 26. Key Term - Product Backlog Using Scrum we always do the most valuable work first! Product owner’s (with input from the rest of the Scrum team and stakeholders) are responsible for determining and managing the sequence of work. This prioritized list is known as the product backlog.
  • 27. ScrumMaster (Delivery Manager) Master tasker, knows how to get stuff delivered ● Works with the Product Owner to define the roadmap for any given product and translate this into user stories ● Enforces process ● Prevents and remove impediments ● Tracks metrics ● Facilitates Daily Scrum
  • 28. Development Team Builders of high-quality, working software. ● Self-organizes to determine the best way to accomplish the goal set out by the product owner ● Creates their own tasks ● Pulls stories from the Product Backlog ● Owns the sprint backlog ● Provides estimates and commitments
  • 30. Scrum activities at Bond 1. Daily stand-up 2. Sprint planning 3. Sprint review 4. Retrospective
  • 33. In this section we will cover: ● Overview of daily standup ● Format ● Best practices
  • 34. What is the daily stand-up? Meetings are typically held in the same location and at the same time each day. Ideally, a daily scrum meeting is held in the morning, as it helps set the context for the coming day's work. These scrum meetings are strictly time-boxed to 15 minutes. This keeps the discussion brisk but relevant. How we relentlessly prioritize the day’s work
  • 35. Daily stand-up - format All team members are required to attend scrum meetings. Each team member answers the following three questions: 1. What did you do yesterday? 2. What will you do today? 3. Are there any impediments in your way?
  • 36. Daily stand-up - best practices ● The daily stand-up meeting is not used as a problem-solving or issue resolution meeting. ○ Issues that are raised are taken offline and usually dealt with by the relevant subgroup immediately after the meeting. ● Any impediments that are raised in the scrum meeting become the delivery manager’s responsibility to resolve as quickly as possible.
  • 38. In this section we will cover: ● Overview of sprint planning ● What is “Ready” for work ● Acceptance criteria ● Story points ● Planning poker ● Velocity
  • 39. What is Sprint planning? During the sprint planning meeting, the product owner describes the highest priority features to the team. The team asks enough questions that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog. Defining the "What" and "How" the Scrum team will deliver
  • 40. Sprint planning - general rules ● Attended by the product owner, scrum master, and scrum team for the upcoming sprint ○ In addition to development team, could potentially include design/UX resources ● Held for 1-2 hours at the beginning of a sprint ● Important to book a conference room and allot proper time (1 hour for every week of sprint to plan)
  • 41. Purpose of sprint planning Sets up the entire team for success throughout the sprint. During sprint planning we define: 1. The sprint goal 2. The sprint backlog
  • 42. Key Term - Sprint Goal A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner.
  • 43. Key Term - Sprint Backlog The sprint backlog is a list of the product backlog items the team commits to delivering plus the list of tasks necessary to delivering those product backlog items. It’s the product owner’s job to make sure all items being discussed are “ready”.
  • 44. What makes a backlog item “Ready”? "Ready" items should be clear, concise, and most importantly, actionable. ● "Ready" means that stories must be immediately actionable ● The Team must be able to determine what needs to be done and the amount of work required to complete the backlog item ● The Team must understand the acceptance criteria and what tests will be performed to demonstrate that the story is complete
  • 45. Acceptance Criteria (A/C) Sets clear expectation as to when a team should consider something done. ● Product owners are responsible for creating A/C and validating whether work is complete ● It helps the team to break down the user stories into task(s) ● Unique for each backlog item ● A ticket without criteria, should not be considered "ready"
  • 46. Bond format for A/C I will consider this done when… ● -Action a yields x result ● -Action b yields y result ● -Action c yields z result Typically there should be at least 4, no more than 12 actions described.
  • 47. A/C differs from the “Definition of Done” A/C is unique to every backlog item. The Definition of Done (DoD) is a clear and concise list of requirements that the user story must satisfy for the team to call it complete. The DoD must apply to all items in the backlog.
  • 48. Definition of done at Bond Examples at Bond: ● Passed QA and code review ● Unit test written ● Seen by and approved by the Product Owner
  • 50. The Good “As a Bond employee, I want a dropdown from live search with corresponding fields.”
  • 51. Why is that a “good” example? ● Clear A/C with fringe rules outlined for the feature ● Expectation for how feature should behave once user interacts ● Limits for how feature should be implemented are clear ● Visual or prototype attached to the ticket
  • 52. The Bad “As a Bond employee, I want to create an invoice for a user.”
  • 53. Why is that a “bad” example? ● Overly complex for a single item, thus A/C is more work then could be completed in a single sprint ○ This should have been split into multiple tickets ○ Every single editable field could have been individual ticket ● Specific visual spec is not attached to ticket ● Not all work is actionable at moment
  • 54. The Ugly “As a Bond employee, I want to see success or failure on my interactions with Skyfall.”
  • 55.
  • 57. Draw me a house
  • 58. Draw me a house I will consider this done when: ● There is a door on the lower floor in the middle of the house ● On each side of the door there is a window ● On the upper floor, there are three windows evenly spaced across the house ● The house has a pitched roof. ● There is a chimney ● The house has a garage ● The house has a fence around a garden ● The fence has a gate ● There is a path from the door of the house to the gate ● The garden has a tree
  • 59.
  • 60. Questions on sprint planning, definition of “ready”, or acceptance criteria?
  • 61. Story points and estimation Now that our backlog item’s are ready it’s time to estimate story points. Story points are a measure of the relative size of a backlog item, taking into account factors such as complexity and physical size.
  • 62. We use planning poker for estimation ● The goal of planning poker is to gather consensus among team members ● The work we agree to do, is the work we agree to complete
  • 63. How planning poker works 1. The product owner describes each item to the team before they estimate it 2. Product owner answers questions regarding functionality to make sure end goal is clear 3. Any member of team who will be contributing to completion votes with planning poker card 4. The majority wins the vote, but for huge discrepancies this is a good time to have dialogue so any potential unforeseen issues are brought up.
  • 64. Guidelines for story points ● Issue that is understood and can be done and deployed in under an hour ≤ 3 ● Issue requiring a bit of understanding but can be done in a few hours = 5 ● Issue requiring research and thought before implementation = 8 ● Issue requiring potentially multiple days and efforts to accomplish = 13 ○ Max hours for a 13 point ticket = 16 hours
  • 65. How much is too much? Using “Velocity” to predict a team’s capacity for work. At the end of each iteration (sprint), the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity. Past velocity is a great indicator for how many story points to include in a sprint.
  • 66. Planned vs. actual velocity Planned velocity is the total number of story points that the team has committed to for the sprint. Actual velocity is the total number of story points the team completes during the sprint.
  • 67. Expect the unexpected It’s the product owner’s role to prevent the the team from over-committing. Other factors that influence velocity: ● Holidays ● Time off for members of team ● Internet/heat outages
  • 68. Time-boxing sprints is absolutely critical The fixed start and end dates are a commitment between team members that you will take on and complete X amount of work, and in the allotted period of time. If we allow sprints to run past the timebox it ruins the ability to accurately predict the future amount of work a team can accomplish (velocity).
  • 69. What happens when you don’t timebox?
  • 70. The perils of not time-boxing ● The 200 point sprint was only possible because we did not adhere to the timebox rules ● We began enforcing timeboxed sprints and at first it was ugly. A sprint with only half the points completed ● With timeboxing, preparation is much more thorough before starting work, thus what we “commit to complete,” we expect to deliver
  • 71. Format for Sprints at Bond How to use Jira for planning and starting sprints. ● Sprint Goal ● Sprint Name ○ Year/Month/Date started ○ This makes it easy to look at prior sprints
  • 72. What have we learned today? ● What is agile development ○ The agile manifesto ● What is Scrum ○ Roles and activities ● Daily stand-up ● Sprint planning ○ How to plan and start a sprint ○ What is “Ready” for work ○ Acceptance criteria ○ Story points ○ Planning poker ○ Velocity
  • 74. Further resources ● Daily stand-ups ● Sprint planning ● Sprint reviews ● Sprint retrospective ● Jira agile guidelines

Editor's Notes

  1. When Jeff Sutherland created the scrum process in 1993, he borrowed the term "scrum" from an analogy put forth in a 1986 study by Takeuchi and Nonaka, published in the Harvard Business Review. In that study, Takeuchi and Nonaka compare high-performing, cross-functional teams to the scrum formation used by Rugby teams.
  2. Best practices: Having them all be of the same duration. Always exceptions but 2 weeks is solid general rule. Not changing the scope (or personnel) during the sprint.
  3. Is typically five to nine people in size; its members must collectively have all skills needed to produce good quality, working software.
  4. Best Practices: The product owner doesn't have to describe every item being tracked on the product backlog. A good guideline is for the product owner to come to the sprint planning meeting prepared to talk about two sprint's worth of product backlog items.
  5. Bond Tip: The sprint goal can be used for quick reporting to those outside the sprint. There are always stakeholders who want to know what the team is working on, but who do not need to hear about each product backlog item in detail.
  6. Best Practices: Sprint backlog Is continuously updated similar to product backlog (and is PO’s job as well).
  7. Why A/C is important (cont.) -Acceptance criteria is the contract that binds what the Product Owner (PO) wants to what the Development Team delivers. -Creating acceptance criteria is one of the most important jobs a product owner has -Without acceptance criteria, very difficult to understand effort needs to complete user story or task. -Different from definition of done.
  8. Just draw me a house exercise. (Takes about 20 minutes or so).
  9. 5 minutes or less.
  10. 10 minutes and unpack the difference.
  11. 5 minutes or less.
  12. Best practices; -Team members will have questions—“what should we do if … ?” “What if the user does … ?”. PO answers these. -Product owners, however, generally do not hold up cards during Planning Poker sessions. -If not using planning poker cards, we use Fibonacci sequence.
  13. Bond Tips: Break items estimated higher than 13 down into multiple tickets