Scrum Fundamentals

1.

SCRUM
Fundamentals
By Ira Zavushchak

2.

Agenda
• Agile Intro
• SCRUM intro
• SCRUM Framework
ü Roles
ü Time boxes
ü Artifacts
ü Definition of “Done” & Definition of “Ready”
• Increment
• Velocity
• Estimation & Planning
• QC in Scrum

3.

Agile intro

4.

Agile intro
Agile is a time boxed, iterative approach to software delivery that builds software
incrementally from the start of the project, instead of trying to deliver it all at once near
the end.
It works by breaking projects down into little bits of user functionality called user stories,
prioritizing them, and then continuously delivering them in short two week cycles called
iterations.

5.

Agile intro

6.

How Does it Work?
1. You make a list
Sitting down your customer you make a list of features they would like
to see in their software. We call these things user stories and they
become the To Do list for your project.

7.

How Does it Work?
2. You size things up
Then, using Agile estimation techniques, you size your stories relatively
to each other, coming up with a guess as to how long you think each
user story will take.

8.

How Does it Work?
3. You set some priorities
Like most lists, there always seems to be more to do than time allows.
So you ask Your customer to prioritize their list so you get the most
important stuff done first, and save the least important for last.

9.

How Does it Work?
4. You start executing
Then you start delivering some value. You start at the top.
Work your way to the bottom.
Building, iterating, and getting feedback from your customer as you go.

10.

How Does it Work?
6. You update the plan as you go
Then as you and your customer starting delivering one of two things
is going to happen. You`ll discover:
a. You`re going fast enough. All is good. Or,
b. You have too much to do and not enough time.
At this point have two choices. You can either
a. do less and cut scope (recommended). Or you can
b. push out the date and ask for more money.

11.

Agile Specifics
Analysis, design, coding, and testing are continuous activities
You are never done analysis, design, coding and testing on an Agile project. So long as there are
features to build, and the means to deliver them, these activities continue for the duration of
the project.

12.

Agile Specifics
Development is iterative
Iterative development means starting with something really simple, and adding to it
incrementally over time. It means evolving the architecture, accepting that your requirements
are going to change, and continuously refining and tweaking your product as you go.
Planning is adaptive
When reality disagrees with their plans, Agilists find it easier to change their plans than reality.
The call this adaptive planning.

13.

Agile Specifics
Working software is the primary measure of success
The rate at which teams can turn their customer`s wishes into working software is how Agilists
measure productivity. Project plans, test plans, and analysis artifacts are all well and good but
Agilists understand they in themselves are of no value to the end customer.

14.

Why Agile?
Agile is about working smarter, rather than harder.
Agile is about generating more value with less work.

15.

SCRUM
intro

16.

SCRUM intro

17.

Definition of Scrum
Scrum became one of the most popular
framework for dealing with complexity.
It is proven daily by wide usage of Scrum
not only in software development but
also in other areas.

18.

Scrum Values

19.

SCRUM intro

20.

SCRUM intro

21.

SCRUM intro

22.

SCRUM
Components

23.

Scrum Components
Roles
Time boxes
• Product Owner
• Scrum Master
• Development Team • Sprint
• Sprint planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective
Artifacts
• Product Backlog
• Sprint Backlog
• Burndown Charts
• Increment
• Definition of “Done”

24.

Scrum Roles
Roles
Events
• Product Owner
• Scrum Master
• Development Team • Sprint
• Sprint planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective
Artifacts
• Product Backlog
• Sprint Backlog
• Burndown Charts
• Increment
• Definition of “Done”

25.

Product Owner
PO is responsible for maximizing the value of the product and
the work of the Development Team.
ü Defines the features of the product
ü Decides on release date and content
ü Responsible for the profitability of the product (ROI)
ü Prioritizes features according to market value
ü Adjusts features and priority every iteration, as needed
ü Accepts or reject work results

26.

SCRUM Master
The Scrum Master is responsible for ensuring Scrum is understood
and enacted. Scrum Master do this by ensuring that the Scrum Team
adheres to Scrum theory, practices, and rules.
ü Responsible for the Scrum Artefacts
ü Developing and nurturing group dynamics
ü Removing the barriers between the team and the customer
ü Serving as a mirror to the team
ü Provide support to Product Owner
ü Update himself to teach and mentor the team and organization
ü Responsible for helping the team to maintain the big picture

27.

Development Team Size
Optimal Development Team size is small enough to
remain nimble and large enough to complete
significant work within a Sprint (typically 7+/-2 people).
Smaller Development Teams may encounter skill
constraints during the Sprint, causing the Development
Team to be unable to deliver a potentially releasable
Increment.

28.

Development Team
The Development Team consists of professionals who do
the work of delivering a potentially releasable Increment of
“Done” product at the end of each Sprint.
ü Only members of the Development Team create the Increment
ü Empowered to manage their own work
ü Team members have all skills needed to create a product Increment
ü Scrum recognizes no titles for Development Team members, regardless
of the work being performed by the person
ü Individual Development Team members may have specialized skills and
areas of focus, but accountability belongs to the Development Team as a
whole

29.

Scrum Events
Roles
Events
• Product Owner
• Scrum Master
• Development Team • Sprint
• Sprint planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective
Artifacts
• Product Backlog
• Sprint Backlog
• Burndown Charts
• Increment
• Definition of “Done”

30.

Scrum Events Characteristics

31.

Sprint
The Sprint is a time-box of one month or less during which a
“Done”, useable, and potentially releasable product increment is
created.
ü 1-2 weeks iteration
ü Team does work from product backlog
ü Team commits to achieve the sprint goal
ü Team plans work for sprint on a Sprint Planning Meeting
ü Team demos work completed on a Sprint Review Meeting
ü Every day team highlights progress on a Daily Scrum Meeting
ü Sprint Burndown chart is used to visualize team progress

32.

Scrum Events On a Timeline

33.

Canceling a Sprint
Canceling a Sprint is most frequently the result of a dramatic shift in business priorities.
Abnormal Termination
Sprint can be cancelled
üSprint Goal becomes obsolete
üSprint no longer makes sense given the circumstances
Only the PO has the authority to cancel the Sprint
If Sprint is terminated, next steps are:
ü Any ‘done’ Product Backlog items are reviewed to understand if they
represent a potentially shippable increment
ü All other Product Backlog items are put back on the Product Backlog
with their initial estimates. Any work done on them is assumed to be lost.

34.

Sprint Planning
The work to be performed in the
Sprint is planned at the Sprint
Planning.
ü Once per Sprint
ü 8 hours for one month
Sprint
ü Addresses two questions:
What? and How?
This plan is created by the
collaborative work of the entire
Scrum Team.

35.

Sprint Planning
ü The Development Team works to forecast the
functionality that will be developed during the Sprint.
ü The Product Owner discussed the objective that the
Sprint should achieve and the Product Backlog items
that would achieve the Sprint Goal.
ü The Scrum Master teaches the Scrum Team to keep it
within the time-box.

36.

Sprint Planning

37.

38.

Daily Scrum
The Daily Scrum is a 15-minutes each day timeboxed event for the Development Team.
At it, the Development Team plans work for the
next 24 hours.
This optimizes team collaboration and
performance by inspecting the work since the
last Daily Scrum and forecasting upcoming
Sprint work.

39.

Daily Scrum
Everyone answers 3 questions, which aren’t not status for the Scrum Master, but they are
commitments in front of peers
What has been accomplished
since the last meeting?
What is going to be done
before the next meeting?
Is anything on your way?

40.

Daily Scrum
The Scrum Master enforces the rule that only
Development Team members participate in the Daily
Scrum.
The Product Owner may be present, but as an observer
only.
The Development Team uses the Daily Scrum to inspect
progress toward the Sprint Goal and to inspect how
progress is trending toward completing the work in the
Sprint Backlog.
Daily Scrums improve communications, eliminate other meetings,
identify impediments to development for removal, highlight and
promote quick decision-making, and improve the Development
Team`s level of knowledge.

41.

Daily Scrum

42.

Sprint Review
A Sprint Review is held at the end of the Sprint to
inspect the Increment and adapt the Product
Backlog if needed.
During the Sprint Review, the Scrum Team and
stakeholders collaborate about what was done in
the Sprint.
Participants in the Sprint Review typically include:
ü Product Owner
ü Development Team
ü Scrum Master
ü Other Stakeholders

43.

Sprint Review

44.

Sprint Retrospective
The Sprint Retrospective is an opportunity for
the Scrum Team to inspect itself and create a
plan for improvements for the next Sprint.
Two questions each team member should
answer during the Sprint Retrospective:
ü What went well during the last Sprint?
ü What can be improved?

45.

Sprint Retrospective
Whole team gathers and discusses what they’d like to:
Start doing
Continue doing
Stop doing
• Team tries to fix 3-5 the most important items during the next sprint
• At the beginning of each retrospective meeting team reviews items that were selected previous
time

46.

Sprint Retrospective

47.

Scrum Artifacts
Roles
Events
• Product Owner
• Scrum Master
• Development Team • Sprint
• Sprint planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective
Artifacts
• Product Backlog
• Sprint Backlog
• Burndown Charts
• Increment
• Definition of “Done”

48.

Product Backlog
The Product Backlog is an ordered list of everything that might be needed in the product
and is the single source of requirements for any changes to be made for product.
ü The requirements for the product
ü A list of all desired work on the project (enhancements, functions, bug fixes)
ü Ideally expressed such that each item has value to the users or customers
ü Prioritized by the Product Owner
ü Reprioritized at the start of each sprint
This is the Product
Backlog

49.

Make the Product Backlog DEEP

50.

Product Backlog Example
Backlog item
As a house owner, I want to see Christmas Tree in living
room, so that to celebrate the Christmas
As a house owner, I want to have New Year decorated
windows, so that people can see nice windows from the
outside
As a guest, I want to have sitting place, so that to have a
rest during celebration
As a guest, I want to have ability to listen the music, so
that I can dance
As a guest, I want to have different dishes on the holiday
table, so that do not be hungry on celebration
...
User Stories are simple, clear,
Estimate
brief descriptions of
(story points)
functionality that will be
valuable for a user or customer
8
of a product.
5
1
3
21
30

51.

User Story
As a <type of user>, I can <goal> so that <reason>
As a guest, I want to
have sitting place to
have a rest during
celebration
As a guest, I want to
have ability to listen
the music so that I can
dance
As a house owner, I want
to see Christmas Tree in
living room, to celebrate
the Christmas

52.

Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected
for the Sprint, plus a plan for delivering the product Increment
and realizing the Sprint Goal.
ü Tasks the Team performs to turn Product Backlog items into a “done”
increment
ü All of the work that the Team identifies as necessary to meet the Sprint
goal
ü Team modifies Sprint Backlog throughout the Sprint (Adds tasks, estimates
remaining work, delete tasks)
Only the Team can change its Sprint Backlog during a
Sprint.
Only the Team can change the contents or the estimates.
This is the Sprint
Backlog

53.

Sprint Backlog Example
Tasks
Mon
Tue
Wed
Thur
Fri
As a house owner, I want to see Christmas Tree in living room, so that to
celebrate the Christmas
Select and measure a place for the
1
0
0
0
0
Christmas Tree
Select color, size and style for Christmas
decorations (toys, Christmas tree ornaments
3
0
0
0
0
etc)
Buy Christmas Tree
4
0
0
0
0
Buy Christmas decorations
8
8
6
7
0
Install Christmas Tree
0.5
0.5
0.5
0
0
Decorate the Christmas Tree
3
3
3
3
3
As mother to take a look if this is what she
expected
0.5
0.5
0.5
0.5
0.5

54.

Increment
At the end of a Sprint, the new Increment must be “Done”, which means it must be in
useable condition and meet the Scrum Team`s definition of “Done”.
All the work that needs to be done for the currently implemented features has been done
and technically the product can be shipped.

55.

Definition of “Done”
To ensure transparency everyone within Team must have a shared understanding of what
it means for work to be complete. This is the definition of “Done” (DoD).
Definition of “Done” may vary from team to team, although if there are multiple Scrum
Teams working on the system or product release, the development teams on all of the
Scrum Teams must mutually define the DoD.
The more mature the Team is, the more stringent criteria for higher quality must be
included to their DoD.

56.

Definition of “Done”
Increment built during Sprint must be potentially shippable, so it must be “done”.
An example of “Done”:
üCoded / implemented
üPeer reviewed
üCode is run against current version in source control
üCode is commented in source control and checked in
üTest Case Specifications are updated and executed with no failures
üAll critical and blocker bugs found, resolved and verified
üUnit Tests written and passing (0 failing in your build components)

57.

Levels of DoD

58.

Definition of “Ready”
A Definition of “Ready” enables a team to specify certain pre-conditions that must be
fulfilled before a story is allowed into an iteration.
Definition of “Ready” helps:
ü To provide clarity to a Product Owner or Product Owner Teams on what it means to create ready backlog
items
ü To ensure transparency
ü To prevent problems before they have a chance to start
DoR list example:
ü All stories must meet the INVEST criteria
ü An estimate
ü Acceptance criteria with examples

59.

Release Burndown chart
Burndown charts show the amount of work remaining in the project, release, iteration or
epic/feature.
ü Records the sum of remaining Product Backlog
estimated effort across time
ü Initial estimates can be changed
ü Trend line is drawn based on the changes in
remaining work
ü The Team is responsible for all estimates

60.

Sprint Burndown Chart
A Sprint Burndown chart tracks
the completion of work throughout
the sprint.
Amount of work planned for the
Sprint can be in:
ü Story Points
ü Hours
Days in Sprint

61.

Estimation and Planning
Story points – type of estimation of the effort of
product backlog items
Velocity – is how much product backlog effort a team
can handle in one sprint
ü Number of story points to be “Done”
ü Incomplete stories don’t count

62.

Velocity
Velocity is the average amount of work a Scrum
team completes during a Sprint, measured in story
points.
Velocity measures how much functionality a team
delivers in a Sprint.
Planned Velocity is a sum of story points/idealhours planned before sprint start.
Average Velocity is calculated for a few last Sprints
(at least 3 last Sprints).

63.

Estimation and Planning
How to evaluate user story?
ü The “bigness” of user story
ü Unit-less values
ü Relative values
ü Typically Fibonacci numbers are used:
v 1, 2, 3, 5, 8, 13…
ü Other options
v T-Shirt sizes: XS, S, M, L, XL, …

64.

Planning Poker
Planning Poker – is a consensus-based technique for estimating!
ü Each estimator is given a deck of cards, each card has a valid estimate written on it
ü Product Owner reads a story and it’s discussed briefly
ü Each estimator selects a card that’s his or her estimate
ü Cards are turned over so all can see them
ü Discuss differences (especially outliers)
ü Re-estimate until estimates converge

65.

QC in SCRUM

66.

Agile Testing Practices
ü Exploratory testing
ü Acceptance testing
ü Regression/integration iterations/sprints
ü TDD and Unit Testing
ü Continuous Integration/Build Process/Version Control
ü Pair Programming, Collective Code Ownership
ü Test-Driven not Defect-Driven
ü Worry-based Testing
ü Quality Driven Development

67.

Test-Driven not Defect-Driven QC
The Role of QC:
ü
Our job should not be to find defects
ü
Our job should be to prevent defects
ü
A quality process builds quality into the code
ü
If you routinely find defects during verification – your process is defective

68.

Quality Driven Development
• Be involved in the day to day of development
ü QC should be present in every single important decision taken during development. They
should also be aware of what the code looks like through daily code reviews or pair
programming
• Have qualified and skilled employees
ü QC should drive the development, and that requires QC personnel to be very skilled and
qualified
• Keep continuously updating the customer
ü QC should make sure that the application as it’s developed is fulfilling the customer’s
expectations. It should also be their duty to guarantee that new requirements are
identified, and also to identify previous requirements that are not necessary anymore

69.

Challenges or/and Issues

70.

Challenges
Who Says "DONE"?
A new "peer to peer" relationship between development and QC personnel
ü Is all about building self-organized teams, and the voice of a QC engineer carries
the same weight than a developer
ü You will become a Subject Matter Expert
Less Time For Testing Purpose
Looking for ways to optimize testing will be a "must"
ü Use Exploratory Testing & Automation throughout the sprint
ü Leverage development resources to work on automated scripts

71.

Challenges
Common Vision/Responsibility
Team develops a common vision of the system
ü Gone are the days of "give me requirements" and "I will give you bugs and reports
back“
Need to Think About Risks Early
Risks are addressed in early iterations
ü e.g. server application with 10,000 concurrent users and <1s response: quickly build
and evaluate components and/or architecture

72.

Challenges
What Do Users Want?
Continuous feedback from users
ü To build what the users want
Early Quality
Early quality control: testing and reviews
ü Review testing artifacts (test plans, strategies, cases)
ü Review developed artifacts (code review, review of unit tests)
ü UX review

73.

SoftServe Confidential