Getting Started with

Scrum
Week 3 & 4
Week 2 Summary:
Running a pilot study
Steps in running a pilot study

1. Form the team

2
Scrum Framework - Overview
Roles Rituals Artifacts
• Scrum Master • Sprint • Story
• Product backlog
• Product Planning • Sprint backlog
Owner • Daily Standup • Scrum board
• Development • Sprint Demo • Definition of
Team • Sprint "done“
• Velocity charts
Retrospective • Burndown chart
• Product increment
Week 3 & 4 Overview
Roles Rituals Artifacts
• Scrum Master • Sprint • Story
• Product backlog
• Product Planning • Sprint backlog
Owner • Daily Standup • Scrum board
• Development • Sprint Demo • Definition of
Team • Sprint "done“
• Velocity charts
Retrospective • Burndown chart
• Product increment
SCRUM - Incremental process
• Scrum at the project level
• This approach is taken “when necessary” (from the Latin pro re nata, or PRN, which means “take
when needed”). It is used, for example, when someone requires software within 30 days or less.
• how to implement Scrum at the project level with minimum overhead and the quickest results.
• Scrum at the capability level
• A software studio is created separate from the rest of the organization.
• tasked with creating competitive advantage using Scrum.
• operates with a high degree of autonomy and is unhampered by bureaucracy.
• as the benefits from Scrum become apparent, the studio’s use will increase
• Scrum at the enterprise level
• The learning from the software studio is extended into the entire organization, to its overall
productivity and agility.
• Covering how to use Scrum to implement Scrum
• how to distinguish between talking the Scrum talk and walking the Scrum walk.
Scrum Framework
Scrum Framework - Overview
Roles Rituals Artifacts
• Scrum Master • Sprint • Story
• Product backlog
• Product Planning • Sprint backlog
Owner • Daily Standup • Scrum board
• Development • Sprint Demo • Definition of
Team • Sprint "done“
• Velocity charts
Retrospective • Burndown chart
• Product increment
Scrum Framework
Roles
Scrum Master
Scrum Framework - Overview
Roles Rituals Artifacts
• Scrum Master • Sprint • Story
• Product backlog
• Product Planning • Sprint backlog
Owner • Daily Standup • Scrum board
• Development • Sprint Demo • Definition of
Team • Sprint "done“
• Velocity charts
Retrospective • Burndown chart
• Product increment
All roles are equal in Scrum
Scrum Team - Scrum Master
• find developers to form the Development Team
• glue that ties a scrum team together
• no authority over others
• discussions about individual roles and duties
• may be a part of the development team
• may have no involvement in the day-to-day development
• focused on development team
• servant leader
Servant leader
• delicately balanced position a scrum master occupies
• no formal authority
• leads the team
• embracing and evangelizing the concepts of scrum
• eliminate blockers (impediments to the scrum workflow)
• coaching people about how to follow the practices of scrum
• lead by example when advocating for and defending scrum
Scrum Master - Responsibilities
• Some critical rituals that a scrum master must observe (more details
later)
• the daily standup
• the sprint planning meeting
• the end-of-sprint demo
• the sprint retrospective
Scrum Master - A Day in the Life
• planning and hosting the rituals of scrum, including the daily standup, the sprint planning
meeting, the sprint demo, and the sprint retrospective
• assisting the team in identifying blockers that get in the way of their development work
• soliciting help from team members, product owners, or anyone in the organization who can
help remove blockers and get stories going again
• maintaining the artifacts of scrum and making sure everyone has access to them
• coaching team members about their roles and responsibilities, while watching for problems
and helping to resolve them
• working with the product owner to help clarify stories and maintain a well groomed backlog
• representing the needs of scrum to management and across the organization for the sake of
the product and the team.
Scrum Master
• host on a daily basis is the fifteen minute standup with the entire
team, and any guests
• involved in a number of follow-up discussions at the end of the
standup
• removing blockers from team members who cannot move forward without
coordinated assistance
• meet with constituents (product owners and team members) to
follow up on any other issues that were raised during the standup
• ensure time constraints are honored
Scrum Master
• Updating the artifacts of scrum – daily duty
• allows anyone to see at a glance what the team is working on, to support the
essential transparency that keeps scrum working.
• calculating and reporting on team metrics such as velocity, and
clarifying the relevance of these concepts to people outside the team
• recognize issues when they manifest
• coach the team when issues arise
• preparing reports on the team's status in plain language
Scrum Framework
Roles
Product Owner
Scrum Framework - Overview
Roles Rituals Artifacts
• Scrum Master • Sprint • Story
• Product backlog
• Product Planning • Sprint backlog
Owner • Daily Standup • Scrum board
• Development • Sprint Demo • Definition of
Team • Sprint “done”
• Velocity charts
Retrospective • Burndown chart
• Product increment
Product Owner
• has a shared responsibility to the team and to the customer
• voice of the customer
• stands in as the representative of the customer's needs, wants, and
expectations
• usually belongs to a department such as Product or Customer Support
• spends time working with customers directly to understand their
needs
• translate these into clear descriptions that the team can estimate and work
on, using a consistent format we call stories in scrum terminology
Product Owner
• keeps an eye on the big picture from the customer's perspective
• looking at the overall state of the product and the timeline for release
cycles
• the changing technical landscape, while deciding what features are
the highest
• priority for the team to work on in the next sprint
Product Owner
• work with designers to make sure user experience flows have been considered, and
that design assets are ready for the team.
• work with QA engineers to verify that the necessary acceptance criteria are accounted
for in the test suite for a story.
• collaborate with the scrum master to help remove blockers from outside the team
• works closely with the team to decide
• if desired feature is technically achievable, given the practical constraints of the team and the
technology
• to plan out the sequence of stories based on their historical development velocity and their
feedback about the product
• close to the team is vital
• so developers can ask about details of a story and confirm the progress of their work.
• usually attend all of the scrum rituals.
One Person Should Not Be Both Scrum
Master and Product Owner
• Product owner has a duty to the client or customer first
• usually isn't part of the engineering department.
• Scrum master
• center around sustainable productivity
• may not align with the organizational objectives of anyone reporting outside
the department.
Product Owner - Responsibilities
• clarifying the needs of the customer
• developing a backlog of product features to work on
• writing clear stories that communicate the full expectations for the product
• meeting the standards of the team
• well-written story encapsulate
• the full intention for a distinct slice of functionality,
• any acceptance criteria
• customer's justification for needing this particular feature
• product owner and the scrum master will collaborate to make sure each
story is ready for the team
Product Owner - Responsibilities
• diligently working on stories that may be needed
• keeps track of stories
• organizes them to make sure the sequence of development is planned out
efficiently and to the expectations of the customer
• if the team runs out of work in the current sprint
• outlining and drafting items that reflect the customer's anticipated
needs for sprints in the near future
Product Owner - Responsibilities
• doesn't need to do detailed planning more than a sprint or two ahead
• stories written too far in advance are so frequently discarded or rewritten
• usually a waste of time to spell them out in much detail.
• maintains a vision for how the product will evolve as individual
features
• keeping in mind the importance of setting the stage in the current sprint for
features that may be needed in the future
Product Owners - A Day in the Life
• meeting regularly with customers to share information about the team's
progress and gather feedback about what the customer wants next
• working directly with designers to plan and prepare assets for the team
• getting technical approval from the team for stories in development
• verifying the completeness and relevance of the QA test suite
• coordinating with the scrum master to make sure everyone has the
information they need to do their work
• meeting with team members when asked to clarify issues and make decisions
• writing stories and grooming the product backlog so it reflects the current
visionfor the product
Product Owner
• like to attend the team's daily standup ritual
• generally not permitted to ask questions or give feedback until after
every member of the team has presented, unless asked directly
• will often follow up on issues that were raised during the standup
with the relevant parties, either on the team or outside.
Product Owner
• constantly watching team progress
• prerogative to adjust the order of the stories in the current sprint if it
appears that a critical functionality is in danger of not being
completed soon enough.
• prioritize the backlog of stories that are ready for the team to start
work on if they run out of stories in the current sprint
Product Owner
• ready to answer questions about the stories that are in progress
during the sprint.
• is in daily communication with the customer to report on progress
and get insight into any issues that may be on the customer's mind
• Writing and refining stories for the next sprint
• grooming the backlog of stories to meet the customer's vision for the
product
• working with designers to make sure that everything the team will
need to work on for these stories will be ready for them
 Scrum Framework
Roles
Development Team
Scrum Framework - Overview
Roles Rituals Artifacts
• Scrum Master • Sprint • Story
• Product backlog
• Product Planning • Sprint backlog
Owner • Daily Standup • Scrum board
• Development • Sprint Demo • Definition of
Team • Sprint "done“
• Velocity charts
Retrospective • Burndown chart
• Product increment
Development Team
• teams consist of a set of four to eight engineers
• skilled at decomposing big requirements into small actionable things that they can
develop in a Sprint.
• estimate the effort to develop the requirements into completed software
functionality.
• Because they will be doing the work, they should make the estimates.
• accuracy depends on
• how long the developers in the team have worked together
• how well they understand the technologies involved
• how well they understand the business or problem domain
• When the planning is complete, the developers forecast what work they believe
they can do by the end of the Sprint.
Development Team - Pair Programming
• engineers to work together
• matching people with different levels of experience to work together on the
same code, so each can benefit from the perspective of the other
• knowledge is shared across the entire team
• what the product is doing
• how to develop every part
• silos of information that reside only in the head of a single engineer
are discouraged
• may appear to go a little slower
• But deeper shared context will develop
Development Team - A Day in the Life
• developing, checking, testing, and documenting code
• getting clarifications, story details, and feedback from the product
owner
• participating in the rituals of scrum
• working with the scrum master to remove blockers for fellow team
members.
Development Team - Responsibilities
• quality of the product being developed
• supported by the team's ability to accept or reject stories
• If stories aren't fully clear, or that may be impossible/impractical given the history of the
project
• estimating the effort involved to complete a story
• measured in arbitrary points, is assigned by the team to help establish how much work they
can do within a timeframe
• preservation of the scrum process
• push back against any attempts to sacrifice quality
• tracking the overall quality of the codebase
• proposing stories that would refactor the existing code to enhance maintainability
Development Team - Responsibilities
• preservation of the scrum process
• anyone interrupts the standup or tries to introduce changes to a story in the
middle of a sprint, every team member should feel authorized to interrupt
that behaviour
• failing to defend the scrum process is letting the other team members down
Scrum Framework - Overview
Roles Rituals Artifacts
• Scrum Master • Sprint • Story
• Product backlog
• Product Planning • Sprint backlog
Owner • Daily Standup • Scrum board
• Development • Sprint Demo • Definition of
Team • Sprint "done“
• Velocity charts
Retrospective • Burndown chart
• Product increment
Scrum Rituals
Scrum Framework - Overview
Roles Rituals Artifacts
• Scrum Master • Sprint • Story
• Product backlog
• Product Planning • Sprint backlog
Owner • Daily Standup • Scrum board
• Development • Sprint Review • Definition of
Team • Sprint "done“
• Velocity charts
Retrospective • Burndown chart
• Product increment
Scrum Rituals
• face-to-face gathering in real time
• targeted communication with each other
• favors communication over documentation
• NOT ANOTHER MEETING
• Every ritual
• has a specific objective
• addresses a particular audience
• defined time frame
Scrum Rituals
• scrum master
• host each of the rituals
• focus on their objectives
• produce the desired results
• everyone
• Knows before the ritual starts what to expect
• how to behave
• what the result of the commitment is supposed to be
Time Boxing
• everybody aware of exactly how long they have committed for a
specific ritual
• how far along they are at any point
• keep a large clock visible
Scrum Rituals
Overview
Scrum Framework - Overview
Roles Rituals Artifacts
• Scrum Master • Sprint • Story
• Product backlog
• Product Planning • Sprint backlog
Owner • Daily Standup • Scrum board
• Development • Sprint Demo • Definition of
Team • Sprint "done“
• Velocity charts
Retrospective • Burndown chart
• Product increment
One- Week Sprint
Ritual
Sprint Planning
• marks the beginning of each sprint
• hosted by the scrum master
• person responsible for the content that goes into a sprint planning is
the product owner
Sprint Planning - Objective
• set the agenda for the upcoming sprint
• an introduction to the stories that should be completed during the next
sprint.
• product owner shows how the stories fit into the vision for the product
• the team commits to completing as many as they believe they're capable of,
given their historical velocity
• determined by the number of points they've been able to complete
• At the end of the sprint planning
• commitment to a certain set of stories
• stories should all be clear,
• amount of work they represent should be within the capacity of the team
Sprint Planning - Time Box
• may take several hours
Sprint Planning – Preparation
• Before sprint planning, product owner will have been working with
designers, customers, various team members, and the scrum master
to create a backlog of clear and specific stories
Sprint Planning – (a) Introducing New
Stories
• product owner goes over the stories, presenting them to the team for
evaluation
• Team members
• participate actively
• opportunity to question and challenge the completeness and appropriateness
of each story
Sprint Planning – (b) Story Estimation
• estimate the relative level of effort required to accomplish each story
• based on team's experience with similar stories in the past
• estimating is that the values assigned to the different stories are
arbitrary and relative
• bear no resemblance to actual time
• to improve the team's ability to look at a new story
• figure out how
• much effort it'll take relative to other stories
Sprint Planning – (b) Story Estimation
• Estimation method: Points
• a smaller, easy story may be estimated at one point
• a large or complex story may be assigned 20 points
• get a sense of how many points they can accomplish within the single
sprint
• everybody on the team to agree to the point estimate for a story,
Sprint Planning – (c) Committing to a
Sprint Backlog
• Once all the stories that the product owner has presented have been
estimated, all the participants in the ritual work together to come up
with a backlog that makes sense for the upcoming sprint
• The end product of a sprint planning is a sprint backlog that everyone
on the team can agree to
Bugs
• has a specific definition in scrum
• are missed requirements for stories that are still in progress
• that have already been accepted as done in a prior sprint
• no points are assigned for fixing the bugs to bring the story to a done
state
Tasks
• Tasks relating to code maintenance should be included in the work
done by the team, and prioritized in the sprint backlog
• should not be estimated with points
• usually does not deliver any tangible user value
• but needs to be done
• Eg
• code re-factoring
• infrastructure changes
Spikes
• stories that require deeper research
• not assigned points
• clear and agreed outcome for each spike
• the more spikes that are required to accomplish the goals of the
product owner, the lower the number of points the team can
accomplish in a sprint
Scrum Framework - Overview
Roles Rituals Artifacts
• Scrum Master • Sprint • Story
• Product backlog
• Product Planning • Sprint backlog
Owner • Daily Standup • Scrum board
• Development • Sprint Demo • Definition of
Team • Sprint "done“
• Velocity charts
Retrospective • Burndown chart
• Product increment
Scrum Artifacts – Product Backlog
Scrum Artifacts – Product Backlog
• stories for the development team emerge from the product owner's
product backlog
• product backlog keeps track of
• all the input the product owner has about the direction of the product from
the client,
• the research,
• experience testing,
• design,
• engineering feedback the product owner has gathered
Scrum Artifacts – Product Backlog
• don't need to be structured in any particular way
• main purpose is to allow the product owner to keep track of all of the
features that are needed
• items may be quite vague until they crystallize into a clear
development story for the sprint backlog
• always reflect the product owner's latest thinking about the long-term
goals for the product
Scrum Artifacts – Product Backlog
• there doesn't have to be a one-to-one correspondence between
items in the product backlog and stories that make it into the sprint
backlog
• features and requirements may turn into multiple stories, or several
items may be combined to create one unified story of the appropriate
size and scope for development
Scrum Artifacts – Product Backlog -
Example
• if the customer needs to add a payment system to a site, that may be
a single story for the development team, or it may be multiple stories
• There may be developer stories around creating the ability to accept
payments through a service, and separate stories for accepting credit
cards, checks, or even maintaining a token system so that purchases
can be made using a virtual currency. It might be possible to develop
each one of these independently, and launch the system with just one
• Whichever one goes out first may need to carry the weight of
implementing some core functionality that all the others will share
Scrum Artifacts – Product Backlog
• find it convenient to track the state of items in the product backlog
using a staged process,
• the item moves from ideation through design through engineering validation,
until it's ready to be phrased as a sprint backlog story and added to an
upcoming sprint.
• Product owners should have a clear sense of what it takes to move an
item from each of the states to the next, and that should be
documented so it'll be consistent for each story.
Scrum Framework - Overview
Roles Rituals Artifacts
• Scrum Master • Sprint • Story
• Product backlog
• Product Planning • Sprint backlog
Owner • Daily Standup • Scrum board
• Development • Sprint Demo • Definition of
Team • Sprint "done“
• Velocity charts
Retrospective • Burndown chart
• Product increment
Scrum Artifacts – Story - Formula
Scrum Artifacts - Story
• how the product owner communicates to the development team
what needs to be developed
• describes a feature to be worked on
• should capture a complete slice of functionality
• independent
• so that developers don't have to complete one story before working on
another
• small slice of functionality that can be worked on
• completed over the course of a single sprint
Scrum Artifacts - Story
• capture the essence of a feature
• give the team the ability to discuss the parameters and acceptance
criteria
• estimating work by sizing feature stories around what the team can
accomplish in a sprint
• every story should add to the value of the product
• bring it closer to the vision of the product owner
• each story should make it clear how the product owner will test the
final product to verify that the story has been completed
Scrum Artifacts - Story
• product owner
• responsibility for writing the stories
• writing good story takes time to develop
• critical to an effective scrum process
Scrum Artifacts – Story - Formula
• Name: brief understandable feature name
• As a type of user
• I want to behavior
• so that justification for the behavior
• Acceptance Criteria:
• Given a defined state
• when a set of conditions or events
• then a consistent and testable result
Scrum Artifacts – Story – Formula -
Example
• Name: Rating Gallery Images
• As a gallery viewer
• I want to rate the images
• so that I can track and rank the images I've rated
• Acceptance Criteria:
• Given a logged-in user viewing a gallery
• when the user clicks a star in a rating widget for an image
• then the value of that star should be recorded as that user's rating for that
image
Scrum Artifacts – Story – Formula –
Example (con’t)
and
• Given a logged-in user viewing a gallery
• when an image the user has rated is displayed
• then the rating widget should reflect the user's previously entered rating

and
• Given a logged-in user viewing a gallery
• when the "Favorites" switch is toggled on
• then only images the user has rated should be shown, in descending order
of rating
Scrum Artifacts – Story
• the team may have a standard for how wireframes or designs get
attached to stories and communicated.
• For example, if this is a new widget, the designer may have prepared
a mockup and a set of assets that the engineers will need in order to
implement the feature
• There may also be a style guide or other documentation for the
product that needs to be updated with the relevant information
Scrum Artifacts – Story
• story is presented at sprint planning,
• the engineers should verify that all of the necessary assets and information
they'll need have been captured & are available.
• The actual work to be done in the upcoming sprint is defined by the
description on the story card and the dialogue it inspires between the
product owner and the team.
Scrum Framework - Overview
Roles Rituals Artifacts
• Scrum Master • Sprint • Story
• Product backlog
• Product Planning • Sprint backlog
Owner • Daily Standup • Scrum board
• Development • Sprint Demo • Definition of
Team • Sprint "done“
• Velocity charts
Retrospective • Burndown chart
• Product increment
Scrum Artifacts - Scrum Board
Scrum Artifacts - Scrum Board
• tracks the progress of all the stories being worked on in the current
sprint until it meets the team's definition of done
• provide a focus for the entire team
• anybody on the team should be able to get an immediate snapshot of
where the sprint stands, and how the team is progressing toward
meeting the goals it set for itself
• good scrum board should be public
Scrum Artifacts - Scrum Board - Tools
• Trello - http://www.trello.com
• Trello (with scrum plugins) - http://scrumfortrello.com/
Scrum Framework - Overview
Roles Rituals Artifacts
• Scrum Master • Sprint • Story
• Product backlog
• Product Planning • Sprint backlog
Owner • Daily Standup • Scrum board
• Development • Sprint Demo • Definition of
Team • Sprint "done“
• Velocity charts
Retrospective • Burndown chart
• Product increment
Scrum Artifacts – Sprint Backlog
• is the set of developer stories that the team has committed to working on during the
current sprint
• these stories emerged from the thinking process that came out of the product
backlog
• may not reflect a specific item in the product backlog
• size of the sprint backlog
• based on the negotiations that happened during sprint planning at the beginning of the sprint
• Each story has a point value, and that reflects the amount of work the team believes
will be necessary to complete that particular story.
• Each story point value is estimated during the sprint planning, and the backlog as a
whole should represent the total number of points that the team believes it can
accomplish in the upcoming sprint
Scrum Artifacts – Sprint Backlog
• developers pick stories from the top of the sprint backlog every time
that they complete a story and need something new to do
• that's the one the product owner considers the highest priority in the current
sprint.
• Picking stories that aren't from the top of the backlog will result in
work being done out of priority order.
Scrum Example -
WithKittens
How Scrum Works
Scrum Process Example - WithKittens
• WithKittens team
• six engineers
• image processing specialists
• back-end data processing
• API management engineers
• front-end engineers for both web and mobile interfaces
• billing and security experts
• one product owner
• product management for both desktop and web applications
• one scrum master
• working together for about three years
Scrum Process Example - WithKittens
• Other members
• dedicated designer on the design team
• a pair of QA engineers
• a small team of DevOps engineers
• site running and also handle IT issues
Scrum Process Example - WithKittens
• unique facets of the service
• figuring out the ideal positioning of kittens in pictures
• best ways to optimize images for proper delivery
Why Just Kittens?
• founder and CEO of the company has a long history of working with
cat rescue societies
• idea for the service began as something to support one local
nonprofit organization, and grew quickly as other nonprofits
• users decided they also wanted to be able to add kittens to their
pictures
Scrum Process Example - WithKittens
• produce both a website and a mobile application designed to add pictures of kittens
to any image uploaded by their clients
• free tier customers (most)
• adding kittens to their own social media images and sharing them
• paying customers (some)
• for the privilege of knowing only the very best kittens will be added to their images
consistently and reliably
• great deal more control over the quality and content than free users get
• high-end social media users
• people who want more control over the way their kittens are presented in their pictures
• growing business clientele, including companies who use theWithKittens service to add
appeal
• important to keep paying clients happy
Problem at Kitten Haven
• the company's focus on kitten-only content has never been a serious
issue before
• but recently, the company's largest clients, a multinational marketing
conglomerate were planning to switch contracts to a competitor. They
puppy images
Memo from Head of Sales
CEO & Product Owner
• Meeting between CEO and product owner
• value of adapting to changing market expectations
• the appropriateness of adding a service that conflicts with the historical
intent of the company
• conflict with company name
• decided to work on puppy-friendly features
• keeping in mind are the overhead of maintaining an entirely
independent service versus the cost of developing and supporting an
integrated service
• scheduled to work on next
Product Backlog
• product owner goes back to the product backlog
• where all future ideas for the service are tracked
• product owner decides the best approach will be to ask the team to
• clone some sections of the WithKittens service and create a minimal
parallel WithPuppies service
• the product owner calls one of the senior engineers in for a chat, and
confirms that this would be the more technically straightforward
approach
Formulating a Feature
• create a scaled down version of the product exclusively for web users
• deployment testing system to limit the audience to a small
percentage of visitors
• visitors will be presented with a link that offers to show them puppies
instead of kittens as soon as they log in
• they click that link, they'll be taken out of the WithKittens.com
domain and redirected to WithPuppies.com
• the experience of WithPuppies.com will be the same, except kittens
will be replaced with puppies
Lining up Design Resources
• sitting down with the designer and discussing some of the visual and
user experience issues
Writing Stories
• product owner writes feature stories around the idea of creating a parallel
WithPuppies site
• best way to describe what will be needed is using stories the team has worked on
before
• by creating additional pages in the content creation flow
• skinned versions of existing pages, with different options presented
• use the existing alert and feedback features
• triggered for a percentage of visitors
• anticipate some of the questions the engineering team will be likely to ask
• acceptance criteria for story
• specific about what percentage of visitors will be tracked to this new experience
• provide information about the availability of design and copy changes
Story Format
New puppy feature
• As a logged-in user who has been selected for the puppy beta
• I want to be able to opt-in to view puppy-specific options during the content
creation process
• so that I can have the benefit of including puppies in my content
• Main acceptance criteria
• Given a logged in user who is randomly (five percent) or explicitly assigned to
the puppy beta
• when that user is viewing the content creation pages
• that user should be shown an alert banner offering to include that user in the
puppy beta
Story Format
and
• Given a logged-in user who has opted in to the puppy option
• when that user views the content creation pages
• that user should see puppies instead of kittens in all of the options, and a
customized feedback form, and an alert banner with an opt-out link
and
• Given a logged-in user who has not opted in to the puppy option
• when that user views the content creation pages
• that user should see the standard kitten site with no indication of puppies or
a puppy beta
Presenting and Estimation
electronic scrum board
after sprint 10
Current Status of Scrum Board
• two stories still in progress
• one that has been completed
• not yet approved by QA before the demo
• All the other stories from that sprint have been accepted at the demo,
and are now done
• completed eleven points during sprint 10
Sprint Planning
• product owner explain
• background of new story
• reads new story
• asks for feedback
Sprint Planning – New Story (1)
• Engineer 1: Why the puppies can't be integrated into the existing site,
instead of being separated out
• Engineer 2: Integrating a different type of animal would make
managing the data much more complicated
• Engineer 1: But won't the customers be confused when they come to
a kitten site and get taken to a page without any kittens?
• Engineer 2: It'll be just as confusing if they get offered kittens and
puppies on a site that's clearly just about kittens. Besides, the whole
navigation is built around kittens, including the URL scheme and the
API.
Sprint Planning – New Story (2)
• Engineer 1: Besides, the whole navigation is built around kittens, including the URL
scheme and the API. Everything about our site says it's about kittens.
• Product Owner: We'll have to handle that with messaging. This is a limited test,
and people who opt in will have to do so intentionally, understanding that this is a
beta.
• Engineer 1: Are all those edge cases handled in the copy?
• Product Owner: Yes, I have messaging written for all of those conditions, and I
plan to make myself very available to the team in case things come up while
working, so we can address them without interrupting progress
• Scrum Master: OK, does everybody know enough about the story that they feel
comfortable estimating it?
• Engineer 1: I think we need a little more clarity on the scope of this.
Sprint Planning – Defining Scope
• Engineer 1: So how is this going to affect the experience of the rest of
the site? I see that the user who's chosen to see puppies will only
see puppies on this particular page, but what about on the rest of
the site?
• Product owner: The scope of the changes will be limited to the pages
being changed. That means the test users might experience a visual
disconnect when they leave these pages and navigate to other parts
of the site, such as the billing and confirmation pages. After all, we've
got a lot of kittens and kitten-related themes running through all the
pages. But it's out of scope to make broader changes to the entire
site just for this test.
Sprint Planning – Defining Scope
• Engineer 2: Is there something else we can do? We have the alert only on
these pages. Can we have them on the rest of the site as well?
• Product owner: I'm worried about making changes that will affect people
not involved in the test. I don't want to make this any bigger than it has to
be, and I certainly don't want to put the stability of the site as a whole in
danger.
• Engineer 2: I don't think it would be that hard. We already have the ability
to turn on an alert that can be shown on every page of the site.
Remember we did that during the last holiday promotion.
• Product owner: Can we make sure this will be limited to the people who
opted in?
Sprint Planning – Defining Scope
• Engineer 2: Sure, that won't be a problem. In fact, we could even
make it so that the people who are selected for the test could opt in
later, if we wanted to.
• Product owner: I don't think that would be necessary. Let's try to do
this as simply as we possibly can.
Product owner decides that it's sufficient if visitors who have opted in
to the puppies retain the alert about the puppy beta at the top of the
page as long as they are in puppy mode. Remind customers that they
have selected puppies instead of kittens, despite the strongly kitten-
oriented messaging on the rest of the site.
Sprint Planning – Defining Scope
Change
Acceptance criteria
• Given a logged-in user who has opted in to the puppy beta
• when that user visits any other page on the site
• the alert banner at the top of the page should be present, reminding them
that they're in puppy mode, and allowing them to opt out
Sprint Planning – Defining Scope
• Engineer 1: If a visitor has selected puppies, and created content
using puppies, could they lose what they have created if they opt out
elsewhere on the site
• Engineer 2: It depends on how we implement it. But it'll be awkward
to keep the custom elements available for people who have opted
out of puppy mode.
• Product owner: What do folks think would be easiest? Should we try
to retain mixed content, or should we force people to delete custom
content if they disable puppy mode?
Sprint Planning – Defining Scope
• team decides that the best solution
• opt out link on the alert to take people to a page warning them that any
puppy-related content they have created in that mode will be lost when
they opt out.
• an inconvenient but appropriate action for that page during the beta
Sprint Planning – Defining Scope
Acceptance criteria
• Given a logged-in user has opted in to puppies
• when that user clicks the opt-out link
• that user should be taken to a confirmation page warning that
they'll lose any puppy-related content if they opted out
Sprint Planning – Defining Scope
• Product owner: Does that look good to everybody?
• Everyone: Yeah
• Scrum master: Great! Let's vote.
Debating Effort
• Everybody on the team has a deck of cards with numbers on it
• Fibonacci scale (one, two, three, five, eight, thirteen, or twenty)
• When the scrum master calls for a vote
• each of the engineers shuffles through and picks the card that represents the
amount of effort they think this task will take
• Historically, this team assigns twenty points to stories that they don't
believe can be completed within a single sprint
Debating Effort
• Scrum Master: We've got five thirteens and one twenty. Do you want to
tell us why you think this would be a twenty?
• Engineer 1 (who voted twenty): It seems to me like there's a lot of
unknowns. This is the first time we've tried to do something like this,
and I know our database is pretty tightly integrated with the whole
kitten concept.
• Engineer 1: Yeah, you've got a point. We've been talking about re-
factoring out the kitten terminology for a long time, and it's never been
a high enough priority for us to get to it.
• Product owner: Do we really need to do that in order to make this
happen?
Debating Effort
• Engineer 1: The code is going to look really ugly unless we do.
• Product owner: I get that. Is it bad enough that we can't do it just for a test?
• Engineer 1: It's just frustrating that we don't get a chance to re-factor these
things when stories like this come up. We've been talking about this technical
debt for months, and we all know it has to be addressed at some point.
• Product owner: I hear you. I do understand we need to make some time to
clean things up. I'll support making that the next highest priority in the next
sprint after we get this completed. Can the team write up a chore for that,
so we can keep track of it and not keep pushing it down to the bottom of the
pile?
Debating Effort
• Engineer 1: This story would be a lot easier if we did that refactor first
• Product owner: I understand that, but we don't have that luxury right
now. If we can get this prioritized, maybe the issues that come up as
we work through this story will help define how the refactoring needs
to go. Is that a possibility?
• Engineer 2: We'll see
• Scrum master: OK. Can we agree to move forward with this story as a
test—if we get the assurance that the re-factor will be the next top
priority after that?
Debating Effort
• Product Owner: I can agree to that, I guess.
engineer nods
• Scrum master: So does this still feel like a thirteen to everybody,
given what we just talked about?
• Engineer 2: I don't think the code'll be bad enough for a twenty. We
can stick it in a separate branch, and use explicit naming conventions.
As long as it's tagged properly, it'll be easy to back out.
• Engineer 1: Then I guess I can go with thirteen
Debating Effort
• Scrum Master: Great. Then this is a thirteen, and we still need
somebody to take responsibility for writing up the re-factoring chore.
• Engineer 1: I've got it. And I'll be sure to bring it up at the
retrospective, to make sure we commit to it like we agreed.
Agreeing to a Sprint Backlog
Sprint Backlog
Sprint Backlog
• Puppy story is labeled 11-1
• product owner doesn't have any new stories to introduce other than the one
about the puppies
In Progress & In QA
• product owner decides it's more practical to let the engineers working
on those stories to finish them
Sprint Backlog
• sprint backlog: 11
• new story: 13
• all the points for the stories that weren't completed the previous sprint: 6
• QA: 3
• higher than previous velocity average: 18
• But total includes several points from stories already partially
completed
Sprint Backlog
• Scrum Master
• makes sure that everybody in the team agrees
• product owner will be satisfied with the product increment represented by
those stories
• launches the sprint

• Engineer 1
• set aside time to write up a chore for the refactoring that's needed, so it can
be introduced as soon as possible
To be continued….
Scrum Story
Week 3 & 4 Summary
Roles Rituals Artifacts
• Scrum Master • Sprint • Story
• Product backlog
• Product Planning • Sprint backlog
Owner • Daily Standup • Scrum board
• Development • Sprint Demo • Definition of
Team • Sprint "done“
• Velocity charts
Retrospective • Burndown chart
• Product increment