This is an overview of the flavor of agile/scrum I had my team use at Bond in Q2 2017. We heavily emphasized the importance of having a shared language between cross-functional teams and this deck was meant as a primer that could be shared between product managers, designers, and developers.
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.
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
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.”
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).
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
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.
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.
Is typically five to nine people in size; its members must collectively have all skills needed to produce good quality, working software.
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.
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.
Best Practices:
Sprint backlog Is continuously updated similar to product backlog (and is PO’s job as well).
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.
Just draw me a house exercise. (Takes about 20 minutes or so).
5 minutes or less.
10 minutes and unpack the difference.
5 minutes or less.
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.
Bond Tips:
Break items estimated higher than 13 down into multiple tickets
