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

5. Agile Overview

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.

9. The Agile Manifesto

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

16. Questions on Agile?

17. Scrum Overview

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

29. Scrum Activities

30. Scrum activities at Bond
1. Daily stand-up
2. Sprint planning
3. Sprint review
4. Retrospective

31. Questions on Scrum?

32. Daily Stand-up

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.

37. Sprint Planning

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

49. Acceptance Criteria Examples

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.”

56. Exercise Break

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

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

73. Questions?

74. Further resources
● Daily stand-ups
● Sprint planning
● Sprint reviews
● Sprint retrospective
● Jira agile guidelines