1. Confidential 10/7/2013 1
AGILE TOUR YEREVAN
05, October, 2013
Succeeding with
SCRUM at be2
Ani Mkrtchyan (Scrum Master)

2. Agenda
2
 Introduction
 Getting started with SCRUM
 Scrum in Details
 Roles
 Artifacts
 Ceremonies
 User Stories
 How to estimate? (Planning Poker)
 Succeeding with SCRUM at be2
 Creating an Effective Product Vision
 Building Quality In
 INVESTing into good User Stories
 How to make SCRUM work?

3. Getting started with SCRUM
3
SCRUM is a simple “Inspect and Adapt” Agile framework that
has three Roles, three Ceremonies, and three Artifacts designed
to deliver working software in Sprints
• Product Owner
• Scrum Master
• Development Team
3 Roles3 Roles
• Sprint Planning
• Sprint Review
• Daily Scrum Meeting
3 Ceremonies3 Ceremonies
• Product Backlog
• Sprint Backlog
• Burndown Chart
3 Artifacts3 Artifacts

4. SCRUM in details
4
3 Roles
SCRUM Team

5. The Product Owner (PO)
5
• Defines the features
• Decides on the release (date &
content)
• Responsible for the profitability of
the product (ROI)
• Prepares the Sprint Planning
Meeting (SPM)
• Prioritizes features according to the
market value
• Accepts or rejects work results
Ultimately responsible for the
Product

6. 6
• Is cross-functional of 6 (+/- 2)
equal members
• Self-organized
• Has the right to do everything
to reach the Sprint goal
• Demonstrates results to the
Product Owner
• Responsible to deliver a
potentially releasable
Increment of “Done” product
each Sprint
The Development Team (TEAM)
Ultimately responsible for Product
Quality

7. The Scrum Master (SM)
7
• Facilitative role that helps PO
and Team in their
responsibilities
• Removes impediments that
are slowing down the Team or
the PO
• “Shields” the team from
external interferences
• Ensures SCRUM works
Ultimately responsible for “guarding”
SCRUM and team self-organization

8. SCRUM in details
8
3 Artifacts

9. Product Backlog (PBL)
9
• Ordered list of everything
that is needed in the product
• The single source of
requirements for any
changes
• Managed by Product
Owner (content, availability,
and ordering)
• Ordered by value, risk,
priority, and necessity

10. Sprint Backlog (SBL)
10
• Product Backlog items
selected for the Sprint
• Includes a plan for
delivering the product
Increment and realizing
the Sprint Goal
• Managed by
Development Team

11. Sprint Burndown Chart (BDC)
11
• Shows the remaining time left to complete the
planned work till the end of the Sprint

12. SCRUM in details
12
3 Ceremonies

13. Sprint Planning Meeting (SPM)
13
• Product Owner invites the Team to
the SPM
• SPM is time-boxed to maximum 4h (2
week Sprint)
• Product Owner presents Sprint Goal
and Product Backlog items starting
from the top of the PBL
• Team discusses the presented User
Stories and asks questions
• Team estimates the work of the
backlog items, called User Stories
• Team Commits to the achievable
amount of items
Scrum Master
Dev Team
Sprint Planning Meeting
PBL

14. Daily Scrum (DS)
14
• Daily Stand-Up meeting is time-
boxed to 15 minutes facilitated by
Scrum Master
• Only “committed” people are
allowed to talk
• Every Team member reports to the
team on:
• What have you done since
yesterday?
• What you will finish by
tomorrow?
• What impediments you got on
your way?
Daily Scrum

15. Scrum of Scrum (SoS)
15
• SoS meeting is time-boxed to 15 minutes facilitated by Scrum
Master
• The frequency for scrum of scrums meetings should be
determined by the team
• One team member from each team is representing his or her entire
team and reports to the rest on:
• What has your team done since we last met?
• What will your team do before we meet again?
• Is anything slowing your team down or getting in their way?
• Are you about to put something in another team’s way?

16. Sprint Review Meeting (SRM)
16
• At the end of every Sprint the
Team invites the PO to the SRM
• SRM is time-boxed to maximum
4h (2 week Sprint)
• Team demonstrates on the real
Product the feature implemented
during the Sprint and asks PO to
accept it
• PO either accepts or rejects
feature
Sprint Review

17. Sprint Retrospective (Retro)
17
• Second half of SRM team
performs self-assessment
• Team applies “Inspect &
Adapt” loop to figure out:
• What went well?
• What went wrong?
• What key changes are
we going to apply at the
next Sprint?
Retrospective

18. User Stories (US)
18

19. User Stories (US)
19
As a user I want to login
so that I am able to use
services on the website.
Acceptance Criteria (AC):
• - I am able to login using
my credentials;
• - If I enter wrong
credentials I am not able
to login and error
message is displayed

20. How to estimate?
20
Find a
Baseline!

21. Planning Poker Game
21

22. 22
Succeeding with
SCRUM at be2

23. 23
Creating an Effective Product Vision

24. 24
Goal:
 To gain insight on the possible release dates and manage and prioritize
product scope (PO)
 Share product roadmap with teams and make sure that entire team
understands direction, goals and vision of the product team
Format:
 RPSs are usually planned outside of a sprint (2 days) to guarantee 100% clear
mind and focus;
 PO prepares items (themes), writes them down on cards and sticks them to
the wall in the conf. room by product areas;
 PO presents the items to team and team estimates them with planning poker.
Outcome:
 Shared clarity about the product future.
Roadmap Planning Sessions

25. Roadmap Planning Sessions
25

26. Building Quality In
26

27. Release Postmortems (aka Bug Retrospectives)
27
Release postmortems are regular retrospective-format meetings focused on
reviewing and understanding reasons for important bugs popped up after LIVE
releases and serve as decision making for preventive actions + follow up to the
actions agreed.
Goal:
 improving overall quality of software releases
Means:
 Analyze missed bugs / incidents occurred case per case (bug by bug,
incident by incident);
 Find root causes for the bugs missed (appear live after deployments);
 Put preventive actions in place (fix the cause not the effect);
 Understand overall defect rates trends (same, worse, better).
 Attendees: release management team

28. INVESTing into good User Stories
28
• Immediately
actionable
• Negotiable
• Valuable
• Estimable
• Sized to fit in
• Testable

29. Backlog Grooming Sessions
29
 Backlog Grooming Sessions (BGSs) are regular meetings that
are held between Product and IT and are driven by PO.
 Goal: be there earlier
 Means: by preparing better for future

30. Backlog Grooming Sessions
30
 To have Less:
 Unknowns;
 Stressful and long SPMs with
“surprises”;
 Questions and impediments during the
sprints;
 Unplanned tasks;
 Technical ad-hoc decisions on the go;
 To have More:
 Time to think & prepare (solutions,
correct estimations, planning, …);
 Shared clarity on the future;
 Granular, INVEST stories by SPM;
 Value delivered;
 Identify problems...
 Estimate stories…
BGSs can be any combination of
activities to:
 Look further…
 Shape stories …
 Break stories down …
 Improve stories…
 Clarify details of the stories...

31. How to make SCRUM work?
31
So what do we need to get SCRUM
going well?
… 5 things!

32. 32
TRANSPARENCY

33. 33
FOCUS

34. 34
TRUST

35. 35
COMMITMENT

36. 36
COURAGE

37. Some guys that do SCRUM
37

38. 38
In order to succeed, your desire
for success should be greater
than your fear of failure.
Bill Cosby

39. 39
Q&A

40. 40
Thanks for your
attention!