CÔNG NGHỆ PHẦN MỀM CHUYÊN SÂU

OVERVIEW OF AGILE DEVELOPMENT

© Copyright 2019 - [email protected]

 Reference Materials

1. Agile Retrospectives: Make Good Teams Great –

Esther Derby, Diana Larsen, Ken Schwaber
2. Agile Estimating and Planning – Mike Cohn
3. User Stories Applied: For Agile Software Development:
Mike Cohn
4. Agile Project Management with Scrum: Ken Schwaber
5. Scrum.Inc
6. Scrum Org
7. Scrum Alliance
8. Scrum Guide

2
© Copyright 2020 - [email protected]
 1: AGILE

© Copyright 2020 - [email protected]

 Content

• Agile Introduction
• Agile vs. Waterfall
• Agile Methodologies
• Agile Practices
• Agile Myths
➔ Section 2. SCRUM Framework

4
© Copyright 2020 - [email protected]
 Traditional Approach
• Waterfall – Predictive approach
– 3 things we wish were true IN WATERFALL
• The customer knows what he/she wants
• The developers know how to build it
• Nothing will change along the way
– 3 things we have to LIVE WITH
• The customer discovers what he/she wants
• The developers discover how to build it
• Many things change along the way

5
© Copyright 2020 - [email protected]
 Traditional Approach (cont.)

6
© Copyright 2020 - [email protected]
 Agile Approach

7
© Copyright 2020 - [email protected]
 Why Are Projects Late?

Third party projects are almost

always late... ...But internal projects are usually worse

• Things change. Over 65% of the • On average, 80% of the cost of a project
requirements change during the is spent up front in the decision process,
average development project. project management, and requirements
• Change is good for business. development.
Competitive bidding means an initial • Implementation starts building
bid has low profit margin. The money assuming nothing will change.
is made on changes billed at time and
materials. • Change control boards try to fend off
change.
• The project has to be late for
vendors to make a lot of money. • By the time it becomes clear that 65%
of the requirements are changing, most
of the time and budget has been spent.
8
© Copyright 2020 - [email protected]
 Why Do Things Change?
• Users don’t know what they want until they see
working product (Humphrey’s Law).
• Since users have to specify all requirements up front,
they put everything but the kitchen sink in the
requirements documents. 65% of features are never or
rarely used.
• Users discover what they want later, particularly
when the business changes. By that time they have
spent their budget on a lot of unnecessary features.

9
© Copyright 2020 - [email protected]
 Not All Features Are Created Equal!
80% of value
typically resides in
20% of features

65% of features provide little to no value,

are rarely used and/or aren’t actually
desired by the customer

The rest are OK,

but not as
important

10
© Copyright 2020 - [email protected]
 The Solution - Get Your
Change for Free
• Create a prioritized backlog of work to be done
with highest business value items first.
• Implement in short sprints, always less than a month.
• When higher priority requirements emerge, put them
in the next sprint.
• Cut lowest priority items out of the project equal to the
amount of work added. These features are unlikely to
be used anyway.
• Change for free allows you to meet your budget and
deliver on time.

11
© Copyright 2020 - [email protected]
 Money for Nothing:
Even Better Than Change for Free

• Projects are usually prioritized by return on investment.

• Ordering your Product Backlog allows you to prioritize
features by return on investment.
• Since 65% are never or rarely used, during the project it
will become evident that the next low priority feature
costs more than the value it delivers.
• Stop the project at that point and deploy the valuable
features.
• All projects should deliver early and save money.

12
© Copyright 2020 - [email protected]
 Value Curve - Radically Faster Delivery

Deliver here at the latest!

80% of value
20% of features

MVP may be here

13
© Copyright 2020 - [email protected]
 Compounding Value - Radically Better Delivery

14
© Copyright 2020 - [email protected]
 Waterfall (Defined process)
vs. Agile (Empirical Process)
• “It is typical to adopt the defined (theoretical)
modeling approach when the underlying
mechanisms by which a process operates are
reasonably well understood.
• When the process is too complicated for the defined
approach, the empirical approach is the appropriate
choice.” ➔ SCRUM is Empirical Process.
Process Dynamics, Modeling, and Control
Ogunnaike and Ray, Oxford University Press, 1992

© Copyright 2020 - [email protected] 15

 Agile vs. Waterfall

16
© Copyright 2020 - [email protected]
 The Agile Paradigm Shift
Waterfall Agile
Fixed Requirements Resources Time

VALUE
driven

PLAN
driven

Estimated Resources Time Features

© Copyright 2020 - [email protected] 17

 What is Agile?
• Agile is about Values and Principles
– People and organizations can not do Agile – they
can be Agile
• Working practices can be Agile and fit into
Values and Principles
– Teams can do Scrum or XP or whatever

18
© Copyright 2020 - [email protected]
 What is Agile?

19
© Copyright 2020 - [email protected]
 What is Agile?

20
© Copyright 2020 - [email protected]
 The Agile Manifesto* (Agile Values)
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right,
we value the items on the left more.”
(2001, Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,
Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern,
Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

* www.agilemanifesto.org

© Copyright 2020 - [email protected]

 12 Agile Principles

1. Our highest priority is to satisfy the customer

through early and continuous delivery of valuable
software.
2. Welcome changing requirements, even late in
development. Agile processes harness change for the
customer's competitive advantage.
3. Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to
the shorter timescale.
4. Business people and developers must work together
daily throughout the project.

22
© Copyright 2020 - [email protected]
 12 Agile Principles (cont.)

5. Build projects around motivated individuals. Give

them the environment and support they need, and
trust them to get the job done.
6. The most efficient and effective method of conveying
information to and within a development team is
face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development.
The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.

23
© Copyright 2020 - [email protected]
 12 Agile Principles (cont.)

9. Continuous attention to technical excellence and

good design enhances agility.
10. Simplicity--the art of maximizing the amount of
work not done--is essential.
11. The best architectures, requirements, and designs
emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behavior accordingly.

24
© Copyright 2020 - [email protected]
 How the manifesto impacts business through
its 12 Agile Principles – Working Software
1. Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software
3. Deliver working software frequently, from a couple of
weeks to a month, with a preference to the shorter
timescale
7. Working software is the primary measure of progress
9. Continuous attention to technical excellence and good
design enhances agility
10. Simplicity - the art of maximizing the amount of work
not done (not need at current) - is essential

* www.agilemanifesto.org/principles.html

© Copyright 2020 - [email protected] 25

 Agile Principles (cont.) –
Responding to Change / Customer Collaboration

2. We welcome changing requirements, even late in

development. Agile processes harness change for the
customer's competitive advantage
4. Business people and developers must work together daily
throughout the project

© Copyright 2020 - [email protected] 26

 Agile Principles (cont.)
– People & Interactions
6. The most efficient and effective method of conveying information
to and within a development team is face-to-face conversation
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done
11. The best architectures, requirements, and designs emerge from
self-organizing teams
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly

© Copyright 2020 - [email protected] 27

 12 Agile Principles ?

© Copyright 2020 - [email protected] 28

 Agile Methodologies

29
© Copyright 2020 - [email protected]
 Agile Practices
• Practices for Effective Teamwork
– Model with Others
– Active Stakeholder Participation
– Collective ownership
– Display Models Publicity
• Practices that enable Simplicity
– Create simple content
– Use the simplest tool

30
© Copyright 2020 - [email protected]
 Agile Practices (cont.)
• Practices for Validation Your Work
– Consider testability
– Prove It with Code
• Pair programming
• Continuous integration
• Feedback loop
• Daily meeting
• Code Review
• Test-Design Driven (TDD)
31
© Copyright 2020 - [email protected]
 Agile Myths
• Agile is a silver bullet
• Agile is anti-documentation.
• Agile is anti-planning.
• Agile is undisciplined.
• Agile requires a lot of rework.
• Agile is anti-architecture.
• Agile doesn't scale.
http://www.agilenutshell.com/agile_myths
32
© Copyright 2020 - [email protected]
 33
© Copyright 2020 - [email protected]
 Section 2: SCRUM Framework

34
© Copyright 2020 - [email protected]
 Group Discussion

• What are the advantages and disadvantages when

applying agile to project?
• What needs to be changed in order to apply agile
to project?
• Why managers need agile?

35
© Copyright 2020 - [email protected]
 Why managers need agile?
Agile is Faster, Better
• Projects can be delivered at 50% of the cost with
40% fewer defects.
• J. Sutherland, C. Jacobson, and K. Johnson, "Scrum and CMMI Level 5: A Magic Potion for Code Warriors!," in Agile 2007, Washington, D.C.,
2007.

• Customers are happier and developers have more fun.

• The agile process is the universal remedy for
software development project failure.
• Software applications developed through the agile
process have three times the success rate of traditional
waterfall method and a much lower percentage of
time and cost overruns.

36
© Copyright 2020 - [email protected]
 Thank you for
your attention!
& See you in
2.SCRUM
FRAMEWORK

37
© Copyright 2020 - [email protected]
 2: SCRUM
FRAMEWORK

© Copyright 2020 - [email protected]

 Content

• SCRUM Introduction
• SCRUM Framework
• SCRUM Roles & Responsibility
• SCRUM Events

➔ Section 3. Artifacts, Events, and More in

SCRUM

39
© Copyright 2020 - [email protected]
 History of SCRUM
• Formalize in 1993 by Ken Schwaber and Dr. Jeff
Sutherland
• Ken Schwaber leads Scrum.org
• Jeff Sutherland leads ScrumAlliance.org (CEO of
Scrum.inc)
• Both organizations can provide Scrum certification
– ScrumAlliance.org – CSM
– Scrum.org – PSM
• In Sep 2014, Scrum.org and the Scrum Alliance agreed
to release a common version of the Scrum Guide
http://scrumguides.org/
40
© Copyright 2020 - [email protected]
 What is SCRUM?
• Scrum is not a process or a technique for
building products
• It is a framework within which you can employ
various processes and techniques

41
© Copyright 2020 - [email protected]
 SCRUM Values

42
© Copyright 2020 - [email protected]
 Principles of Scrum

43
© Copyright 2020 - [email protected]
 SCRUM Pillars

44
© Copyright 2020 - [email protected]
 SCRUM Values & Pillars

45
© Copyright 2020 - [email protected]
 SCRUM Framework

46
© Copyright 2020 - [email protected]
 Now There is a Framework of Continuous
Improvement and Delivery

Daily Scrum Meeting

• Done since last meeting
• Plan for today
• Obstacles? Daily

Sprint Planning Meeting Sprint Demo and Review

• Review Product Backlog
Backlog tasks 2-4 weeks Meeting
• Estimate Sprint Backlog • Demo done items
• Commit to 2-4 weeks of work expanded
by team • Retrospective on the Sprint

Vision
Product Backlog: Potentially Shippable
Prioritized Items Product Increment
Sprint Backlog
desired by Customer • Product Backlog Items assigned to Sprint
• Estimated by team

47
© Copyright 2020 - [email protected]
 SCRUM Roles
• Product Owner
• Scrum Master
• The Development Team

48
© Copyright 2020 - [email protected]
 Product Owner
• Represents the stakeholders and is the voice of
the customer
• Owns the vision of what would be produced to
achieve business success
• Get input from customer, manager, stakeholders
• Turn this into a single list (Product Backlog) of
what would be produced, prioritized based on
business values and risks

49
© Copyright 2020 - [email protected]
 Product Owner
• Responsibility:
– Maximizing the value of the product and the work of the
Development Team
– Managing the Product Backlog
• Clearly expressing PBI (Product Backlog Item)
• Ordering the items in the Product Backlog to best achieve goals
and missions
• Optimizing the value of the work the Development Team
performs
• Ensuring that the Product Backlog is visible, transparent, and
clear to all, and shows what the Scrum Team will work on next
• Ensuring the Development Team understands item in the Product
Backlog to the level needed
50
© Copyright 2020 - [email protected]
 Product Owner

51
© Copyright 2020 - [email protected]
 Product Owner is a Big Job

PO • Initially, one Product Owner may be

able to generate ready backlog for
T T T T T T T T T several teams

• As team velocity increases, a

Product Owner team, led by a Chief
Product Owner, will be needed
CPO
• The Product Owner team are
PO PO

domain experts that describe the

T T T T T T T T T user experience, the screen shots,
the workflow, the data

© 2013 Scrum Inc.

requirements, the look and feel.
52
© Copyright 2020 - [email protected]
 Development Team
• Is responsible for delivering potentially shippable
product increments at the end of each Sprint.
• The ideal team size in SCRUM is 3 to 9 (in scrum guide)
• The team is cross-functional. It has all skills to produce
finished product: designer, coder, tester, etc…
• Everyone contributes based on competency, rather
than job title
• The team is self-organizing and self-managing. It is
responsible for making a commitment and managing
itself to hit the goal. SCRUM provides tool to help team
to do it.
53
© Copyright 2020 - [email protected]
 Development Team (cont.)

54
© Copyright 2020 - [email protected]
 The Development Team (cont.)
• Developer Team:
– No title other than Developer; No sub team
– Accountability belongs the Development Team
as a whole
– Developers, Testers, …..
– Who else do you need to deliver value for the
increment?
– What about the Product Owner?
• Activities:
– Commit to the Sprint
– Plan their work (tasks, dependencies)
– Determine the estimates

55
© Copyright 2020 - [email protected]
 SCRUM Master
• Is responsible for ensuring Scrum (theory,
practices, and rules) is understood.
• Facilitates creativity and empowerment
• Improves productivity of development team in
any way possible
• Improves engineering practices and tools so each
sprint is ready to deploy
• Is a servant-leader for the Scrum Team
• Is not a project manager
• Does not have authority over the team
56
© Copyright 2020 - [email protected]
 SCRUM Master (cont.)
• Service to Product Owner
– Finding techniques for effective Product Backlog
management
– Helping the Scrum Team understand the need for
clear and concise PBIs
– Understanding product planning in an empirical
environment
– Ensuring the PO knows how to arrange the Product
Backlog to maximize value

57
© Copyright 2020 - [email protected]
 SCRUM Master (cont.)
• Service to Development Team:
– Coaching the Development Team in self-organization
and cross-functionality
– Helping the Development Team to create high-value
products
– Removing impediments to the Development Team’s
progress
– Coaching the Development Team in organizational
environments

58
© Copyright 2020 - [email protected]
 SCRUM Master (cont.)
• Service to Organization
– Leading and coaching the organization in its Scrum
adoption
– Planning Scrum implementations within the
organization
– Helping employees and stakeholders understand and
enact Scrum and empirical product development
– Causing change that increases the productivity of the
Scrum Team
– Working with other Scrum Masters to increase the
effectiveness of the application of Scrum in the
organization.
59
© Copyright 2020 - [email protected]
 ScrumMaster Facilitates Team
Organization and Maturity
• Self-organizing teams evolve and grow over time
• A ScrumMaster’s involvement evolves with the team on the
Agile Team Maturity Scale

Low Agile Team Maturity Scale High

More support Time Less support and

needed, facilitation
increased needed, more
ScrumMaster team self
guidance and organization
facilitation

60
© Copyright 2020 - [email protected]
 SCRUM Events
• Sprint
• Sprint Planning
• Daily Meeting
• Sprint Review
• Sprint Retrospective

• And more such as Release Planning, Product Backlog

Grooming, Scrum of Scrum, …
Events
– All events are time-boxed in order to ensure that
appropriate amount of time is spent without allowing
waste in the process
– All events are to enable transparency and a change for
inspection and adaptation.
61
© Copyright 2020 - [email protected]
 Sprint
• A sprint is a constant duration identified for
delivering a product increment.
• Sprints are typically between 1 and 4 weeks
length.
• For a project, all sprints have the same
duration.
• Sprints have a start date and an end date.
• A sprint cannot be closed early unless it is
canceled or is the last sprint for the product.
62
© Copyright 2020 - [email protected]
 Sprint (cont.)
• Only the product owner can decide whether a
sprint can be canceled when it is identified
that the sprint goal is obsolete.
• Sprint occurs one after another without any
down-time between them
• Each sprint is started by a planning meeting
and ended by a sprint review an retrospective
meeting

63
© Copyright 2020 - [email protected]
 Sprint (cont.) - Abnormal
Termination of Sprint

If a sprint is abnormally
Management can cancel
sprint if external terminated, the next step
Sprints can be
circumstances is to conduct a new
cancelled before the sprint planning meeting,
allotted timebox is negate the value
of the Sprint goal where the reason for the
termination is reviewed

64
© Copyright 2020 - [email protected]
 Sprint (cont.) - No Change in Sprint
• No change keeps the team commitment
• During the sprint, what the team committed to
deliver does not change, and the end-date of Sprint
does not change.
• If something major comes up, Product Owner can
terminate the Sprint prematurely, and start a new
one

65
© Copyright 2020 - [email protected]
 Sprint Planning
• Is a negotiation between the team and the product
owner about what the team will do during the next
sprint. ➔ make sure that the commitment is
reasonable
• The product owner and all team members agree
on a set of sprint goals, which is used to determine
which product backlog items to commit from the
uncommitted backlog to the sprint.
• No one should bring pressure on the team to over-
commit;
• Time-boxed: 8 hours 66
© Copyright 2020 - [email protected]
 Sprint Planning (cont.)

• Normally, will be divided into 2 parts:

– Part 1: to decide what will be done in next
sprint
• Input: the latest product Increment, projected
capacity of the Development Team during the
Sprint, and past performance of the
Development Team
• Output: Sprint Goal and PBIs in sprint.

67
© Copyright 2020 - [email protected]
 Sprint Planning (cont.)
– Part 2: to decide how will the chosen work get
done?
• Enough work is planned during Sprint Planning for
the Development Team to forecast what it believes
it can do in the upcoming Sprint
• Work planned for the first days of the Sprint by the
Development Team is decomposed by the end of
this meeting
• If the Development Team determines it has too
much or too little work, it may renegotiate the
selected Product Backlog items with the Product
Owner
68
© Copyright 2020 - [email protected]
 Daily Scrum (Standup Meeting)
• Daily Scrum is a meeting where the team has a
short discussion to update each other progress and
surface blocks.
• During the meeting, each team member answers
three questions:
– What have you done since yesterday?
– What are you planning to do today?
– Any impediments/stumbling blocks?
• Scrum Master notes the block and afterwards helps
to resolve them.
• Even without Scrum Master, the daily meeting still
happens; Team (Required), SM (O) and PO (O)
• Time-boxed: 15’ 69
© Copyright 2020 - [email protected]
 Sprint Review
• At the end of Sprint, Product Owner, Scrum Master
and stakeholders come together and see the demo
of what team has produced.
 An informal meeting, not a status meeting to elicit feedback and
foster collaboration
• The Product Owner gathers feedbacks from
everyone on ways to improve what has been built.
 Inspect the Increment and adapt the Product Backlog if needed.
 Result is a revised Product Backlog

• Time-boxed: 4 hours; Team, SM, PO (R);

Stakeholder (O)
70
© Copyright 2020 - [email protected]
 Sprint Retrospective
• Retrospectives and feedback loops are at the heart
of any successful Agile/Scrum implementation.
• The Retrospective is a chance for the team to act
like a team, hearing every voice, integrating their
perspective and reaching consensus on how to
move forward in the next iteration.
• This is a mechanism for continuous improvement,
and also where critical problems are identified and
addressed or surfaces to management for
assistance.
• Time-boxed: 3 hours, Team (R), SM(R) and PO (O)
71
© Copyright 2020 - [email protected]
 72
© Copyright 2020 - [email protected]
 Thank you for
your attention!
& See you in 3.
Advanced
SCRUM

73
© Copyright 2020 - [email protected]
 3: ADVANCED SCRUM
ARTIFACTS, EVENTS And More

© Copyright 2020 - [email protected]

 • Artifacts Content
– Product Backlog
– Sprint Backlog
– Product Backlog Item (User Story)
• INVEST
• MOSCO
– Definition of DONE
– Definition of READY
– Velocity and Burndown Chart
• Detailed Scrum Events
– Sprint Planning
– Daily Scrum
• Kanban board
• Impediment Management (Risk Management)
– Sprint Review
– Sprint Retrospective
– Product Backlog Grooming 75
© Copyright 2020 - [email protected]
 Scrum Framework
(remind)

76
© Copyright 2020 - [email protected]
 77
© Copyright 2020 - [email protected]
 78
© Copyright 2020 - [email protected]
 79
© Copyright 2020 - [email protected]
 80
© Copyright 2020 - [email protected]
 The Product Backlog
• Items vary in size and detail
• Is always in ranked order
• Priority items are detailed
in time for the next Sprint
Planning Meeting
• Evolves over time and Is
never done
• Is always ready
© Copyright 2020 - [email protected]
 Not All Features Are Created Equal!
80% of value
typically resides in
20% of features

65% of features provide little to no value,

are rarely used and/or aren’t actually
desired by the customer

The rest are OK,

but not as
important

82
© Copyright 2020 - [email protected]
 Why We Prioritize the Product Backlog
Delivered product function usage in a typical system

Often or always Sometimes

used: 20% Rarely
16%
19%

Never
Often
45%
13%

Always
7%
Rarely or never
Standish Group Study Reported at XP2002 by Jim Johnson, Chairman used: 64%
© 2004 Poppendieck LLC

© Copyright 2020 - [email protected]

 84
© Copyright 2020 - [email protected]
 Product Backlog Item
• Attributes
– Description (Spec in SRS)
– Rank/Priority
– Complexity/Cost/Size (Story Points or T-Shirt)
– Optional attributes:
• Business Value ($, L/M/H),
• Owner,
• Tests, Sample results
– Other options?
• Can be defined via a “Story Card”, “User Story”,
“Use Case”, what else?
© Copyright 2020 - [email protected]
 Example: Product Backlog Item as a Story Card

© Copyright 2020 - [email protected]

© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
 PBI as User Story
• User stories are short, simple
descriptions of a feature told from the
perspective of the person who desires
the new capability, usually a user or
customer of the system.
• They typically follow a simple template:
– As a <type of user>, I want <some goal>
so that <some reason>.
• A story should use the I.N.V.E.S.T
acronym
90
© Copyright 2020 - [email protected]
 I.N.V.E.S.T

91
© Copyright 2020 - [email protected]
 PBI as Theme, Epic and Task
• Epic: large story, generally take more than one
or two sprints to develop and test. They are
usually broad in scope, short on details, and
will commonly need to be split into multiple,
smaller stories before the team can work on
them.
• Theme is a collection of related user stories.
• Task is simply more granular versions of the
work entailed to complete a PBI
92
© Copyright 2020 - [email protected]
 Product Backlog Grooming
Activity in during the Sprint
• Look ahead to Product Backlog that’s coming soon
• Split large Product Backlog items into smaller ones
• Start to get more detailed understanding of items
• Begin to think about how they’ll be implemented
• PO, Team and SM do this together each Sprint, at a
time of their choosing, and for a duration of their
choosing Set a regular date and time to do this every
Sprint
• Initially provide about 10% of the time to this activity
and then Inspect and Adapt
© Copyright 2020 - [email protected]
 Product Backlog Grooming (cont.)

94
© Copyright 2020 - [email protected]
 Product Backlog Grooming (cont.)

• An on-going process in which the Product Owner and the

Development Team collaborate on the details of Product
Backlog items.
– Removing stories that no longer appear relevant
– Create new user stories
– Re-assess the relative priority of stories
– Request for the most detailed product backlog items (PBI)
– Add acceptance criteria and define when this item is done
– Light-estimate PBIs
– Only focused on higher ordered PBIs
– [DOR] A GOOD “READY” PBI (user story) is I.N.V.E.S.T 95
© Copyright 2020 - [email protected]
 Product Backlog Grooming (cont.)
PBI Prioritization with MOSCO Technique

96
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
 ➢DoD is not static
▪ The DoD changes over time.

▪ Organizational support and the team’s ability

to remove impediments may enable the
inclusion of additional activities into the
DoD for features or sprints.

▪ Data from retrospectives are added to

DoD as the team learns and
understands better
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
 User Story Mapping
• Epics at top, stories underneath
• Shows workflow
• Can be large features, company initiatives
• Two dimension view easier to understand than
linear ordering
• Tool for identifying MVP
• Allows the team to see the big picture

© 2013 Scrum Inc.

© Copyright 2020 - [email protected]
 User Story Mapping (cont.)

© 2013 Scrum Inc.

© Copyright 2020 - [email protected]
 Sprint Backlog
• The sprint backlog is a list
of tasks identified by the
Scrum team to be
completed during the
Scrum sprint
• During the sprint planning
meeting, the team selects
some number of
product backlog items,
usually in the form of user
stories, and identifies the
tasks necessary to
complete each user story.
110
© Copyright 2020 - [email protected]
 Sprint Backlog (cont.)
➢ Scrum team takes the Sprint Goal and decides
what tasks are necessary to complete the
selected features.
▪ Tasks should be no more than 16 hours in
length; larger tasks need additional
breakdown
➢ Team self-organizes around how they’ll meet
the Sprint Goal.
➢ Scrum Masters don’t make decisions for the team.
➢ Sprint Backlog (a list of tasks to be completed
during the Sprint is created).
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
 113

© Copyright 2020 - [email protected]

 Sprint Planning

➢ Sprint Planning Meeting

▪ Each sprint is preceded by a planning meeting, where the User Stories
for the sprint are identified and an estimated commitment for the sprint
goal is made
1. Product Owner
2. Scrum Team
3. Customers
4. Management

1. Product Backlog
2. Existing Product 1. Sprint Goal
3. Business Conditions 2. Sprint Backlog
4. Technology Conditions
Sprint
Planning
Meeting

© Copyright 2020 - [email protected]

 Sprint Planning (cont.) - INPUT

© Copyright 2020 - [email protected]

 Sprint Planning (cont.) - OUTPUT

© Copyright 2020 - [email protected]

 Sprint Planning (cont.)

© Copyright 2020 - [email protected]

© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
 Relative Estimation
• It is hard to estimate in absolute hours
• The effort in hours could vary from developer
to developer.
• Relative Estimation consists of estimating
tasks or user stories, not separately and in
absolute units of time, but by comparison or
by grouping of items of equivalent difficulty.
• Methods:
– T-shirt Size
– Poker Planning
123
© Copyright 2020 - [email protected]
 Story Point Estimation
• A story point is an arbitrary
measure of effort required
to implement a user story
• A reference story is an
example of a story that we
can fairly well relate to
• A new story can be
compared to the reference
stories and we can tell
whether it is larger or
smaller than each one of
them 124
© Copyright 2020 - [email protected]
 125
© Copyright 2020 - [email protected]
 Estimation: Story Point

• The “bigness” of a task

• Influenced by
– How hard it is
– How much of it there is
• Relative values are what is important
• A login screen is a 2. A search feature is a 8.
• Points are unit-less

126

© Copyright 2020 - [email protected]

 Estimation: Story Point Scale
Value Meaning

0 No effort required
1 No. problem, We could do
this in few hours
2

3
Based on Fibonacci
5 Most common use
sequence, a recurring
organizational pattern 8

13
The story point scale has no
statistically reliable 20
relationship to man hours 40

100 Impossible, this is very large

127 ?… Need more information
© Copyright 2020 - [email protected]
 128

© Copyright 2020 - [email protected]

 Velocity

• Velocity is a capacity planning tool

• Velocity = ∑ Story Points completed in a Sprint
• Estimated Velocity for next Sprint:
– Estimated Velocity = Averages over Last N Sprints
• Velocity normally becomes stable after five or
six sprints
• For the first sprint, just pick up number of
stories that you think the team can finish at
the end of sprint.
129
© Copyright 2020 - [email protected]
 Velocity (cont.)

➢ To understand how unit less story

points would work, we need to
introduce a new concept –
VELOCITY
➢ Velocity is a measure of a team’s
rate of progress. It calculated
summing up the number of story
points completed during a sprint
➢ Therefore if a team completes 5 user
story of 3 points each, then we would
say that the team velocity is 15
➢ Now if a team completes 4 user story
of 5 points each, then we would say
that the team velocity is 20
130

© Copyright 2020 - [email protected]

 Velocity as Productivity

Duration 450/15 = 30 sprints

Calculation Velocity = 15

450 story
Size
points

131

© Copyright 2020 - [email protected]

 Velocity of Team A

Sprint 1 Sprint 2 Sprint 3

24 Points 22 Points 25 Points

of size of size of size

Average of ~ 24 Points per Sprint is the “Velocity”

132

© Copyright 2020 - [email protected]

 Estimation: Stabilization Sprints

Sprint 1 Sprint 2 Sprint 3 Sprint 4

Stabilization
Sprint 1 Sprint 2 Sprint 3
Sprint

➢ During “regular” sprints target friendly first use

▪ Beta customers and similar can use immediately after sprint

➢ During “stabilization sprints”

▪ Team prepares a product for release
▪ Useful during
– active beta periods
– when transitioning a team to Scrum
– if quality isn’t quite where it should be on an initial release

➢ Not a part of standard Scrum, but could be useful

133

© Copyright 2020 - [email protected]

 134
© Copyright 2020 - [email protected]
 135

© Copyright 2020 - [email protected]

 136

© Copyright 2020 - [email protected]

 Burn Down Charts

➢ Are used to represent “work done”.

➢ Are wonderful Information Radiators
➢ 3 Types:

▪ Sprint Burn down Chart (progress of the Sprint)

▪ Release Burn down Chart (progress of release)

▪ Product Burn down chart (progress of the

Product)
137

© Copyright 2020 - [email protected]

 138
© Copyright 2020 - [email protected]
 Release Planning: Example
Product Backlog as made available from the PO

139

Source –2020
© Copyright - [email protected] – Pete Deemer
http://www.goodagile.com
 Release Planning
Assume that now we should only be planning for “Must” + “Should” = 144
144 / 24 = 6 Sprints

Estimation Buffer +15%

Rework Buffer +10%
Additions Buffer +10%

= 8.3 Sprints
Pre-release +1
Sprint = 9.3 Sprints
= 10 Sprints

Idea from – http://www.goodagile.com – Pete Deemer

140

© Copyright 2020 - [email protected]

 Release Burndown Chart

Dev End Release

Source – http://www.goodagile.com – Pete Deemer

110
© Copyright 2020 - [email protected]
 Release Burndown Chart (cont.)

142

Source –2020
© Copyright - [email protected] – Pete Deemer
http://www.goodagile.com
 Release Burndown Chart (cont.)

To release
on time,
remove 35
points of
Backlog
Dev Releas
End e

To release
full scope, 3
extra Sprints
required

143

Source –2020
© Copyright - [email protected] – Pete Deemer
http://www.goodagile.com
 Sprint Planning

Iteration 1 Iteration 2
As a BUYFROM ME user, I 3 As a Shipping Manager , I 5
want to… want to…

As a BUY FROM ME user, I 5 As a BUY FROM ME user, I 2

want to… want to…

Code the UI 8
Write test fixture 6
Code middle tier 12
Write tests 5

“Yesterday I started on the UI;

should finish before the
end of today.”

144

© Copyright 2020 - [email protected]

 Sprint Planning (cont.)
Iteration 1 Iteration 2
As a BUYFROM ME user, I 3 As a Shipping Manager , I 5
want to… want to…

As a BUY FROM ME user, I 5 As a BUY FROM ME user, I 2

want to… want to…

Code the UI 8
Write test fixture 6
Code middle tier 12
Write tests 5
Creating
this is
Sprint
“Yesterday I started on the UI;
planning should finish before the
end of today.”

145

© Copyright 2020 - [email protected]

Estimation: Use Historical Data - Where Possible
Other concept is to use
Yesterday’s Weather (which
means take reference of
Sorted the last couple of
Velocities
iterations and plan for your
27 next one)
34
35
38
Use Median 39
40
40
41 90% confidence interval,
45 Use 39 as your velocity
in the team and plan
your future iterations
146
based on this
© Copyright 2020 - [email protected]
 Estimation: Estimates are shared

➢ Estimates are not created by a single individual on the team

➢ Agile team do not rely on a single expert to estimate
➢ Estimates are best derived collaboratively by the team,
which includes those who will do the work. There are 2
reasons for this:
o First on an agile project, one would not tend to know
who specifically would be working on a given task
o Secondly even though one may not be doing the work (like
for examples specialized testing), others may have
something to say about the estimate
➢ Additional accuracy in estimation efforts
yields very little value beyond a certain
point
147

© Copyright 2020 - [email protected]

 Estimation: Deriving an Estimate

The 3 most common techniques for estimating are:

➢ Expert Opinion
o Ask an expert of the subject, as to how long will it take to do a work.
o The expert relies on their intuition or gut feel and provide an estimate
➢ Analogy
o When estimating by analogy, the estimator compares the story being
estimated with one or more other stories. In this technique one
compares the new story to the assortment of stories already
completed or estimated

➢ Disaggregation
o Refers to splitting a story or a feature into
smaller, easier to estimate pieces.
o It would be very difficult to estimate a single story of
100 days.
o The solutions to this is to break the large story or
148
feature into multiple smaller items and then estimate those
© Copyright 2020 - [email protected]
 Story Points Estimation with
Planning Poker

Simultaneously,
Each person each person
Team shows estimate
discusses chooses their
User Story estimate

Until the
numbers are
close
People with high & low
estimates explain their
reasoning
149

© Copyright 2020 - [email protected]

 Poker Planning
1. Each estimator is given a deck of cards, Each card has a
valid estimate written on it
2. Product owner reads a story and it‘s discussed briefly
3. Each estimator selects a card which is his or her
estimate
4. Cards are shown at the same time, so that everyone can
see
5. Differences are discussed, especially the very high and
low estimates
6. Re-estimate, until an agreement on the estimate is
reached
150
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
 Scrum Board with Kanban Board
• Kanban is a flavor of agile that emphasizes the flow and
continuous delivery of work
1. Visualize your work
2. Limit your work in process
3. Manage Flow
4. Make Process Policies Explicit

155
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
 163
© Copyright 2020 - [email protected]
 164
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
 Sprint Review NOT DEMO
Same people as Team demonstrates that

1 planning meeting plus

any other interested 2 they have completed the
work as planned in the
parties (e.g. end users) Sprint Goal.

Customers / PO can provide

3 feedback, new ideas,
changed requirements,
4 Typically takes the form of
a demo of new features or
underlying architecture
changed priorities.

© Copyright 2020 - [email protected]

© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
 Sprint Retrospective (cont.)

➢ Process improvement at end of every Sprint

➢ All team members reflect on the past sprint
➢ Make continuous process improvements
➢ Two main questions are asked in the sprint
retrospective:
o What went well during the sprint?
o What could be improved in the next sprint?
➢ Facilitated by ScrumMaster
➢ What went well, what could be improved.
➢ Scrum Master prioritizes based on team direction
➢ Team devises solution to most vexing problems

© Copyright 2020 - [email protected]

 Sprint Retrospective (cont.)

1. Set the stage

2. Gather Data
3. Generate Insights
4. Decide What to Do
5. Close The Retrospective

170
© Copyright 2020 - [email protected]
 Sprint Retrospective (cont.)

• 1. Set the stage

– Start with a simple welcome and appreciation for
people’s investment of time
– Restate the purpose of the retrospective and the
goal for the session
– Define the ground rules
– Goes through the agenda
– Define the goals

171
© Copyright 2020 - [email protected]
 Sprint Retrospective (cont.)
• 2. Gather Data
– Create a shared picture on what happened
– Different people have different perspectives on the same
event
– Include both facts and feelings, leads to better thinking
and action in the rest of the retrospective.

• 3. Generate Insights
– What to do differently / What need to be improved
– What need to be keep

172
© Copyright 2020 - [email protected]
 Sprint Retrospective (cont.)
• 4. Decide What To Do
– Pick the top items and decide what to do
– Choose items that they can commit to and that will have a
positive effect.

• 5. Close the Retrospective Meeting:

– End the retrospective decisively: don’t let people (and their
energy) dribble away
– Help your team decide how they’ll retain what they’ve learned
from the retrospective
– Look at what went well and what you could do differently in the
next retrospective

173
© Copyright 2020 - [email protected]
 Sprint Retrospective (cont.)
Example: Typical Issues

None of us feel like we’re

Retrospective is a developing We have a high
waste of time our skills risk of losing team-
members

Our quality is very

We never take action on poor. Open bugs are
We always forget any of the issues we
whatever we piling up.
discuss
agreed to do

Team is under a lot of

We never have time to Team motivation
stress and is starting to
make improvements in our and morale
burn out
We don’t have any way of working are very low
way of reminding
ourselves We never finish what we
We’re always over- committed to in Sprint
committed in every Sprint Planning

Productivity is much
Everyone is micro-managing LOWER than it could
The Product Owner the team be
pressures us into over
committing
The Product Owner gavean in Sprint Planning The ScrumMaster
unrealistic delivery date to isn’t protecting us!
the VP

© Copyright 2020 - [email protected]

 Sprint Retrospective (cont.)
Example: Retrospective Rules

© Copyright 2020 - [email protected]

 176
© Copyright 2020 - [email protected]
 Thank you for
your attention!
& See you in 4.
Pitfall – Best
Practice and
more
177
© Copyright 2020 - [email protected]
 4: Advanced SCRUM
Pitfall – Best Practice
- Handbook

© Copyright 2020 - [email protected]

 Content
• Good characteristics
• Pitfalls (Common Problem)
• Best practices & Lesson Learnt
• more …

179
© Copyright 2020 - [email protected]
 Characteristics - SCRUM Master

• Knowledgeable
• Responsible
• Good team player
• Facilitator
• Good Observer
• Good Listener
• Servant Leader

180
© Copyright 2020 - [email protected]
 Characteristics – Development Team
• Self organizing – Empowered - Collaboration
• Sharing goal and objectives
• Own its decisions & commitment
• Consensus driven
• Constructive disagreement
• Constructive feedbacks
• Trust
• Motivating team
• Believe they can solve any problem 181
© Copyright 2020 - [email protected]
 Pitfalls
• Directive Scrum Master
• Product Owner Specifies Solutions
• Assigning Tasks
• Not Getting Done
• Problem-Solving in the Daily Scrum
• Stretch Goals
• Giving up on Quality

182
© Copyright 2020 - [email protected]
 #1: PO Role Not Defined or Impediments

Ready
Under-Resourced

Done
Typical symptoms What to do about it
• Stories frequently not done at Review due to PO role not defined
external dependencies or in-sprint surprises • Assemble all stakeholders to decide on the single
• Product Owner not available to answer Team tactical PO to work with team
questions in a timely fashion • All backlog should flow to team through PO
• Many stories “discovered” during the Sprint • Set up regular Meta-Scrum meeting for
• Team feels priorities shifting too frequently stakeholders to align without impacting team
• Team gets conflicting messages from different PO role under-resourced
sources • Ensure that each team has its own PO
• Designate separate Strategic (epic-level market
Root causes and ROI) and Tactical (ready backlog) PO to work
closely together
• User stories not clear and READY at start of Sprint • Assign cross-functional PO team
• Needed information not available in time
• Poor clarity on who is responsible for providing
what information
• Unclear who leads story creation/refinement Target end-state
• Product Owner role is not well-defined • Stakeholders have an aligned and compelling
• Single PO creating all backlog for multiple vision that is maintained regularly
teams or all customer engagement thru to • This vision communicated to Team through the
story creation for one accelerating team PO and a consistent Product Backlog
• Product Owner role under-resourced • Backlog stories follow regular refinement process
• Conflicting Team goals from multiple sources to ensure they are ready before Sprint Planning
• Unresolved competing stakeholder interests

© 2013 Scrum Inc.

• Progress communicated back to stakeholders
• Product Owner role is not well-defined
without distracting the Team

183
© Copyright 2020 - [email protected]
 #2

184
© Copyright 2020 - [email protected] 184
 #3: Team Working Individually Impediments

Ready
Rather than Together

Done
Typical symptoms What to do about it
• Team thinks of backlog as a shared “to do” list Pair on Stories
where each PBI is done by only one person: • Encourage collaboration on stories to increase
“those are my stories” the quality of the end product
• Team comprised of Subject Matter Experts • Write stories that provide opportunities to pair
• Bottlenecks created around a single Team • “Divide and conquer” to get Done on priority
member stories quicker
• One person or group typically working long hours
Cross-Train to grow Team’s skillset
to keep up with demand on their time
• Flag scarce skills as a Team impediment
• SME works with one or two Team members to
Root causes help them learn the unique skill
• Lightweight checklists or notation stored in a
• High level of Work in Progress (WIP) Team Wiki for reference for common tasks
• Each team member pulls a different story
• Stories requires skill only one Team member
possesses
• Lower priority stories started before higher Target end-state
priority ones completed • A least two Team members can finish each story
• Next available Team member can’t pull next and ideally anyone can work on any story
high priority story • Work in Progress is low as the Team works
• High priority story depends on scarce skill together on top priority stories
• Need for cross-training on skill • Work flows easily from one to member to
• Team often relies on one hero to “save the day” another
• This person is only one who can do a task

© 2013 Scrum Inc.

• Team members can enjoy vacation without being
• Team works as a group of individuals
needed to deliver work!

185
© Copyright 2020 - [email protected]
 Impediments

#4: Stories Aren’t Ready Before Sprint

Ready
Planning

Done
Typical symptoms What to do about it
• Sprint Planning Meeting is tedious and takes a SM encourage Team to look ahead
long time to complete, maybe even a full day • Adopt mindset of looking forward to anticipate
• Team has many questions during Sprint Planning questions, dependencies and risks
that PO cannot answer during the meeting • Coordinate regular Refinement meetings for
• Stories are difficult to estimate at Sprint Planning Team and PO to discuss future sprints
• At the end of each Sprint there are several • Coach team to utilize INVEST criteria
stories not finished or not even started
PO meet with Team before each Sprint
• Approach specific Team members with questions
needed to prepare Sprint Backlog
Root causes
• Attend Refinement meetings with Team to
• Team writing lots of new stories at Planning explain upcoming work, get Team clarification
• New stories needed to deliver Sprint priorities • Clarify work with stakeholders before Planning
• Team sees upcoming work for the first time
• Team not investing in Refinement
• Lots of unplanned work emerges during the Sprint
• Research or clarification often required to begin Target end-state
work planned • Shorter and more effective Sprint Planning
• Team hasn’t thought all work needed to meetings (1 hour or less per week of Sprint)
deliver the story • Few “surprises” during Sprint that could have
• Team not investing in Refinement been avoided with better planning
• PO needs input from external stakeholders • Team finishes planned work ~80%+ of Sprints
• Team needs more information to plan • Team and PO work together to Refine backlog
• PO hadn’t anticipated required lead time

© 2013 Scrum Inc.

(expect 5-10% of the Team’s time)
• Team not investing in Refinement

© Copyright 2020 - [email protected]

 #5:PBIs Not Broken Down into Small Impediments

Ready

Done
Vertical Slices of Functionality
Typical symptoms What to do about it
• Stories usually involve only one discipline or PBI’s Not Defined As Vertical Slices of
team member (function-centered stories) Functionality
• Stories difficult for team to act on immediately • Make sure every PBI is in “User Story” form, or
• Several stories must be completed before at least Team can identify how PBI generates
functionality would create value for customers incremental customer value
• Multiple days pass without team completing a • Get entire team to agree on clear Definition of
story (uneven burndown) Ready for all Backlog items that aligns with
• Actual work often much greater than estimated target end state
• Have customers participate in Sprint Review to
reinforce customer value perspective
Root causes • Have PO spend more time with Customer and/or
• Team struggles to work together on PBIs get training on writing better user stories
• PBI definition includes only one person/
functionality from team
• Defined from team not user
perspective Target end-state
• Multiple stories must be completed before • Each completed Story delivers a “potentially
incremental functionality ships shippable” increment of value to customer
• PBIs address only one functional element • Multiple team members can “swarm” together on
• Actual work often much greater than estimated priority stories
• Not all team members participate in estimation • Every Story is immediately clear and actionable
for function-centered PBIs • Sprint burns down relatively smoothly
• Team members think “it isn’t my work”

© 2013 Scrum Inc.

• Release Plans are relatively accurate
• PBI not defined as vertical • Velocity is increasing roughly 10% per Sprint
functionality

© Copyright 2020 - [email protected]

 #6: Team Over-Commits to Work Impediments

(or is Committed by Someone Else)

Ready

Done
Typical symptoms What to do about it
• At the end of most Sprints, there are unstarted Team not tracking Velocity
stories or stories not meeting Definition of Done • Each story brought into the sprint should be
• Team is working at a unsustainable pace to try estimated in points
and complete each sprint • All finished points totaled at end of every Sprint
• The number of stories “in progress” remains high • Implement Yesterday’s Weather Pattern for
throughout the sprint Sprint Planning
• Team feels “behind schedule” or under pressure Team is not self-organizing
to finish more output quickly • Align with leadership on expectations for
empowered teams
Root causes • Secure buy in that reality on the ground trumps
the plan
• Team is not completing most Sprints • Team estimates work and commits to how many
• Team over commits during Sprint Planning stories to bring into the sprint
• Team guesses about how much work it can
complete each sprint
• Team is not tracking velocity Target end-state
• Team is working at an unsustainable pace to • Team is tracking Velocity each sprint and all team
complete each sprint members know Velocity if asked
• The team is overcommitted • Team pulls in work equal to the average actual
• Team following a plan that dictates what points completed in recent sprints
must be done by when • Team and PO work together to prepare for Sprint
• Team does not control what work is Planning
brought into the Sprint

© 2013 Scrum Inc.

• Team decides, and is not told, how much work to
• Team is not self-organizing
pull into the Sprint Backlog

© Copyright 2020 - [email protected]

 #7: Found Work Interrupts Impediments

Sprint Regularly

Ready

Done
Typical symptoms What to do about it
• Team frequently (>20%) fails to complete Found works interrupts Sprint regularly
planned work by end of Sprint • Implement the Interrupt Pattern and include
• Team discovers significant unplanned work or Sprint buffer in categories where found work is
receives frequent “surprise” requests from expected
stakeholders that must be addressed right away
• Use Retrospective to identify ways to anticipate
• Team feels like priorities are constantly shifting
• Planned stories don’t move to Done found work better
• Burndown chart is flat External stakeholder requests displace planned work
• Confront leadership with the effect of
Root causes interruptions
• Implement the Interrupt Pattern, include limited
• Significant amounts of “found work” enters sprint buffer for surprise requests, and put PO in path
• Team not anticipating what is needed to to defend team
complete work
• Team is new, or working in unfamiliar area
• Team hasn’t given room in Sprint for Target end-state
learning • Team anticipates some level of unplanned work,
• Build in “buffer” for found work and allows for this in Sprint Backlog
• Frequent surprise requests from stakeholders • Unplanned work is limited to allow planned work
• Stakeholders asking Team directly for work to proceed to completion
• No formal process for handling “urgent” • Team finishes all planned work early, and is able
requests – informal requests add up to pull additional stories from Product Backlog
• Need process for managing,

© 2013 Scrum Inc.

• Velocity increases ~10% each Sprint as planning
prioritizing and limiting mid-sprint and execution improve
external requests

© Copyright 2020 - [email protected]

 If Your Backlog Looks Like This, You Have a
Problem with Interrupts!

© 2013 Scrum Inc.

Source: Revised after Henrik Kniberg
© Copyright 2020 - [email protected]
 Pattern: The Interrupt Pattern
Dealing with the unexpected

Beginning of sprint

Product Sprint
Backlog Backlog Support
Kaizen
8 8 Management
5 5
5 5 PO
Sales
3 Now
3
5
5 5 Buffer
Later
8

5
3
5 Low Priority

© 2013 Scrum Inc.

On Buffer Overflow ABORT, Replan, Dates Slip
© Copyright 2020 - [email protected]
 #8

192
© Copyright 2020 - [email protected]
 #9

This is a blank slide

193
© Copyright 2020 - [email protected]
 Agile Testing

© Copyright 2020 - [email protected]

 Agile Testing (cont.)

© Copyright 2020 - [email protected]

 Agile in PMI-ACP

196
© Copyright 2020 - [email protected]
 Nexus Framework

197
© Copyright 2020 - [email protected]
 Less Framework

198
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
 SCRUM HANDBOOK

© Copyright 2019 - [email protected]

 Content
• Transform Traditional to Agile
• GSOFT SCRUM Handbook

201
© Copyright 2020 - [email protected]
 Transform to Agile (Working Space)

202
© Copyright 2020 - [email protected]
 Transform to Agile (Working Space)

203
© Copyright 2020 - [email protected]
 Transform to Agile (information radiator)

204
© Copyright 2020 - [email protected]
 Transform to Agile (information radiator)

205
© Copyright 2020 - [email protected]
 Transform to Agile (information radiator)

206
© Copyright 2020 - [email protected]
 Transform to Agile (CI/CD)

• Versioning Server ➔ Subversion and Rule?

• Analysis Code ➔ Coding Process?
• CI/CD in some commands
• Team/PO/Stakeholder
• “Solution” Server ➔ “CI Env” for Tester, “Feedback
Env” for PO, Users and Stateholders

… to be continued or TBD

207
© Copyright 2020 - [email protected]
 Transform to Agile (For Team)

• “GSOFT” Scrum Process (Handbook)

• DOR – Definition of Ready • Agile Tooling

• DOD – Definition of Done • prefer low-tech, high-touch tool
• Team Rules over sophisticated computerized
208
• Impediment Management
© Copyright 2020 - [email protected] models
 Transform to Agile (Team Rules)

• Don’t start on Monday

• Test Driven Development
• Pair Programming
• Collaboration Games
• Generally Accepted Scrum Practices (GASPs)
• GASPs can be domain specifics

209
© Copyright 2020 - [email protected]
© Copyright 2020 - [email protected]
 Transform to Agile (For Team)

Master Craftsman
Journeyman • Passionate about the
• Has worked for several craft
years with a master • Guides a team of
Apprentice • Coaches apprentices
journeymen and
apprentices
• Contribute to simple • Learns from masters • Infects the team with
tasks • Spreads knowledge enthusiasm and passion
for the craft
• Learn from journeyman between masters
• Situated learning • Focused on delivering • Has delivered many
applications successful, robust, high-
• Review work of the • Some journeyman will quality applications
master become a master one • Is recognized by users,
• Developing through day, but many will remain customers and developers
demonstrated progress journeymen the rest of • Is responsible for
passing on the craft
© Copyright 2020 - [email protected] their careers
 Transform to Agile (For Team)
• Standard User Story and Story Point
• Estimation Methods:
• Planning pocker: www.planningpoker.com or
https://www.amazon.com/Agile-Sizing-Cards-
Planning-Estimating/dp/B00IM4ETNK
• Product Backlog and
Sprint Backlog use JIRA or
Trello
• Velocity (points)
• Capacity (hours)
©… to2020be continued or TBD 212
Copyright - [email protected]
 Transform to Agile (For PO)
• Product Vision (Story Map)
• Stategy for specifying Value
• Release Planning
• SRS

… to be continued or TBD

213
© Copyright 2020 - [email protected]
 Transform to Agile (Scrum Framework)

214
© Copyright 2020 - [email protected]
 Thank you
for your
attention!

© Copyright 2020 - [email protected]

AGILE - SCRUM
SUMMARY & DISCUSSION
SELF-CHECK QUIZ
▪ Which statement best describes the Sprint Review?
It is a review of the team's activities during the Sprint.
It is when the Scrum Team and stakeholders inspect the outcome of the Sprint and
figure out what to do in the upcoming Sprint.
It is a demo at the end of the Sprint for everyone in the organization to provide
feedback on the work done.
It is used to congratulate the Development Team if it did what it committed to
doing, or to punish the Development Team if it failed to meet its commitments.

▪ The Scrum Master is responsible for what? (multichoice)

Ensuring that the Development Team IS managed
Running the Daily Scrum
Tracking Development Team Status
Ensuring that Scrum is enacted
Ensuring that Scrum is understood
AGILE - SCRUM
SUMMARY & DISCUSSION
SELF-CHECK QUIZ
▪ A Scrum Master is keeping a list of open impediments, but it is growing and
he/she has been able to resolve only a small portion of the impediments. Which
three techniques would be most helpful in this situation?
Prioritize the list and work on them in order.
Alert management to the impediments and their impact.
Arrange a triage meeting with all other project managers.
Discuss the absence of management support with the Development Team.
Tell the Product Owner that Scrum isn't working.
Consult with the Development Team.
AGILE - SCRUM
SUMMARY & DISCUSSION
SELF-CHECK QUIZ
▪ What is the result of Sprint Review?
A completed Sprint Backlog
Critique on the development product Increment
Critique on the Development Team
The Scrum Master's documentation on the Sprint statistics
A revised Product Backlog

▪ The Sprint Goal is devised before the sprint-backlog

True
False
AGILE - SCRUM
SUMMARY & DISCUSSION
SELF-CHECK QUIZ
▪ Who is responsible for updating the work estimates during a Sprint?
The Development Team.
The Scrum Master.
The Product Owner.
The most junior member of the Team.

▪ An abnormal termination of a Sprint is called when?

When it is clear at the end of a Sprint that everything won't be finished.
When the Team feels that the work is too hard.
When Sales has an important opportunity.
When the Product Owner determines that it makes no sense to finish it.
AGILE - SCRUM
SUMMARY & DISCUSSION
SELF-CHECK QUIZ
▪ Who has the last say on the order of the Product Backlog?
The Stakeholders
The Development Team
The Scrum Master
The Product Owner

▪ The Product Backlog is ordered by:

Small items at the top to large items at the bottom.
Safer items at the top to riskier items at the bottom.
Least valuable items at the top to most valuable at the bottom.
Whatever is deemed most appropriate by the Product Owner.

▪ Development Team membership should change:

Every Sprint to promote shared learning.
Never, because it reduces productivity.
As needed, while taking into account the short term reduction in productivity.
Just as it would on any development team, with no special allowance for changes
in productivity.
AGILE - SCRUM
SUMMARY & DISCUSSION
SELF-CHECK QUIZ
▪ Which two (2) things does the Development Team NOT do during the first
Sprint?
Deliver an increment of potentially shippable functionality.
Nail down the complete architecture and infrastructure.
Develop and deliver at least one piece of functionality.
Develop a plan for the rest of the project.

▪ What is the primary way a Scrum Master keeps a Development Team working at
its highest level of productivity?
By facilitating Development Team decisions and removing impediments.
By ensuring the meetings start and end at the proper time.
By preventing changes to the Backlog once the Sprint begins.
By keeping high value features high in the Product Backlog.
AGILE - SCRUM
SUMMARY & DISCUSSION
SELF-CHECK QUIZ
▪ It is important that the product increment be released to production or shipped
to customers at the end of each Sprint?
True
False

▪ When is a Sprint over?

When all Product Backlog items meet their definition of done.
When the Product Owner says it is done.
When all the tasks are completed.
When the timebox expires

▪ The CEO asks the Development Team to add a "very important" item to the
current Sprint. What should the Development Team do?
Add the item to the current Sprint without any adjustments.
Add the item to the current Sprint and drop an item of equal size.
Add the item to the next Sprint.
Inform the Product Owner so he/she can work with the CEO
Agile & Scrum
SUMMARY & DISCUSSION
SELF-CHECK QUIZ
▪ Which statement best describes the Sprint Review?
It is a review of the team's activities during the Sprint.
It is when the Scrum Team and stakeholders inspect the outcome of the Sprint and
figure out what to do in the upcoming Sprint.
It is a demo at the end of the Sprint for everyone in the organization to provide
feedback on the work done.
It is used to congratulate the Development Team if it did what it committed to
doing, or to punish the Development Team if it failed to meet its commitments.

▪ The Scrum Master is responsible for what? (multichoice)

Ensuring that the Development Team IS managed
Running the Daily Scrum
Tracking Development Team Status
Ensuring that Scrum is enacted
Ensuring that Scrum is understood
Agile & Scrum
SUMMARY & DISCUSSION
SELF-CHECK QUIZ
▪ A Scrum Master is keeping a list of open impediments, but it is growing and
he/she has been able to resolve only a small portion of the impediments. Which
three techniques would be most helpful in this situation?
Prioritize the list and work on them in order.
Alert management to the impediments and their impact.
Arrange a triage meeting with all other project managers.
Discuss the absence of management support with the Development Team.
Tell the Product Owner that Scrum isn't working.
Consult with the Development Team.
Agile & Scrum
SUMMARY & DISCUSSION
SELF-CHECK QUIZ
▪ What is the result of Sprint Review?
A completed Sprint Backlog
Critique on the development product Increment
Critique on the Development Team
The Scrum Master's documentation on the Sprint statistics
A revised Product Backlog

▪ The Sprint Goal is devised before the sprint-backlog

True
False
Agile & Scrum
SUMMARY & DISCUSSION
SELF-CHECK QUIZ
▪ Who is responsible for updating the work estimates during a Sprint?
The Development Team.
The Scrum Master.
The Product Owner.
The most junior member of the Team.

▪ An abnormal termination of a Sprint is called when?

When it is clear at the end of a Sprint that everything won't be finished.
When the Team feels that the work is too hard.
When Sales has an important opportunity.
When the Product Owner determines that it makes no sense to finish it.
Agile & Scrum
SUMMARY & DISCUSSION
SELF-CHECK QUIZ
▪ Who has the last say on the order of the Product Backlog?
The Stakeholders
The Development Team
The Scrum Master
The Product Owner

▪ The Product Backlog is ordered by:

Small items at the top to large items at the bottom.
Safer items at the top to riskier items at the bottom.
Least valuable items at the top to most valuable at the bottom.
Whatever is deemed most appropriate by the Product Owner.

▪ Development Team membership should change:

Every Sprint to promote shared learning.
Never, because it reduces productivity.
As needed, while taking into account the short term reduction in productivity.
Just as it would on any development team, with no special allowance for changes
in productivity.
Agile & Scrum
SUMMARY & DISCUSSION
SELF-CHECK QUIZ
▪ Which two (2) things does the Development Team NOT do during the first
Sprint?
Deliver an increment of potentially shippable functionality.
Nail down the complete architecture and infrastructure.
Develop and deliver at least one piece of functionality.
Develop a plan for the rest of the project.

▪ What is the primary way a Scrum Master keeps a Development Team working at
its highest level of productivity?
By facilitating Development Team decisions and removing impediments.
By ensuring the meetings start and end at the proper time.
By preventing changes to the Backlog once the Sprint begins.
By keeping high value features high in the Product Backlog.
Agile & Scrum
SUMMARY & DISCUSSION
SELF-CHECK QUIZ
▪ It is important that the product increment be released to production or shipped
to customers at the end of each Sprint?
True
False

▪ When is a Sprint over?

When all Product Backlog items meet their definition of done.
When the Product Owner says it is done.
When all the tasks are completed.
When the timebox expires

▪ The CEO asks the Development Team to add a "very important" item to the
current Sprint. What should the Development Team do?
Add the item to the current Sprint without any adjustments.
Add the item to the current Sprint and drop an item of equal size.
Add the item to the next Sprint.
Inform the Product Owner so he/she can work with the CEO