Scrum, The Agile Framework

Muhammad Ichsan Rahardianto
© 2017 Muhammad Ichsan Rahardianto. All Rights Reserved.
2
M. ICHSAN RAHARDIANTO
PMO & Scrum Master | PRINCE2® | PSM™ I
Ichsan is a passionate person, he has strong technical background and a wide range of experience in Information Technology field. He is a software architect as well as an
engineer, he has been leading teams and help them to produce great products.
He is a PRINCE2® Certified Project Management Professional and a Professional Scrum Master™ I (PSM™ I) Certified Scrum Master. He has worked extensively on
Software Development Life Cycle (SDLC) and Agile Methodologies.
Hi Everyone, lets learn Scrum & Agile
Hi!

3
Agile /ˈadʒʌɪl/ adjective
Able to move quickly and easily.

4
Agile Ecosystem
Scrum
XP Kanban
DSDM

5
We are uncovering better ways of developing software by
doing it and helping others do it. Through this work we
have come to value:
Agile Manifesto
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.
source: http://agilemanifesto.org/

6
Agile: Embrace changes
Waterfall: Enforce control
Not a Binary OptionAgile vs Waterfall
1
0

7
“Changing practices is one thing; changing minds is
quite another” ― Mike Cohn

8
What is a Car?

9
Le Fardier de Cugnot
source: http://youtube.com/watch?v=KP_oQHYmdRs

10
Nicolas-Joseph Cugnot
1725 - 1804

11
A Carpenter and His Son
source: source: http://youtube.com/watch?v=KP_oQHYmdRs

12
Fixed Well Planned Position

13
Continuos Measurement

14
The Agile Craftsman!

15
Templated Drill Hole Tools

16
Leadership
Style
Nature of
Problem
Management
Objective
Problem-
solving
Approach
Leadership Style
A good leader doesn’t have one well-defined style of
leadership that he/she force-fits all situations to.
• The management objective shapes the problem solving approach
• The problem-solving approach determines the leadership style that may be most appropriate
source: http://managedagile.com/whats-really-different-agile-leadership/

17
Problem-solving
Approach
Empirical process control
approach, means “based on
observation” that both the
definition of the solution as
well as the process to
discover the solution will
evolve based on observation
throughout the project.
Problem-solving
Approach
The solution to the problem
is generally well-defined in
advance and the general
approach for implementing
the solution is also fairly
well-defined.
Leadership Approach
To encourage creativity and
innovation, you don’t want to
emphasize control, you want
to empower people and give
them some flexibility to use
their own intelligence and
judgement.
Management Objective
Arriving at an effective
solution is far more
important in this kind of
project than predictability.
Therefore, innovation and
creativity would generally be
emphasized more than
control.
Management Objective
If predictability is important,
having a well-defined plan
and conformance to that
plan are also important.
Leadership Approach
That calls for a style of
leadership that naturally
might be a bit more directive
in order to remain on track
with the project plan.
Agile Leadership vs Traditional

18
Common Polarized View
Agile is
Good
Waterfall is
Bad
Agile Servant
Leadership is
Good
Command & Control
Management is
Bad

19
Effective Leader Adjust!An effective leader should be able to adjust his/her leadership style and problem-solving approach as necessary to fit any
given situation.
CREATIVE
ADVANTAGESSTYLE
There is not just one leadership style that fits
all situations
Creative
Agile leadership is not really a radically
different style of leadership that is totally
separate and mutually-exclusive with other
leadership styles; however, it significantly
expands our definition of what “leadership” is.
Style
Leadership styles are not necessarily good
or bad saying a particular leadership style is
good or bad is like saying “a car is better than
a boat”. Each has advantages and
disadvantages depending on the environment
you’re in.
Advantages

20
“Project success depends on leadership behaviors, not
processes. And successful Agile projects are led, not
managed” ― Brian Wernham

21
Steel Ladder vs Simple Wooden Ladder

22
The Bigger Picture

23
“It’s not about code, It’s about business” ― Development
That Pays

Build The Right ThingBuild the thing right
24
Picking The Right
Wall
(Business Goal)
More Important Than
Perfect Ladder
(Code)

25
Lets Play Ball!
3 Minutes of planning to distribute the ball from one bucket to
another.Planning
Sprint
Review
Retrospect
5 Minutes of exciting playing games, catching up with the time limit,
distributing from one bucket to another.
5 Minutes of measuring your great effort doing the exercise, and get
you ready for the next iteration.
7 Minutes of team self introspection, what went good or bad, and
how to improve.

LUNCH BREAK

27

28
Ad-hoc processes to share documents, photos, and other electronic media. The handling of the Oklahoma City Bombing
case highlighted the deficiencies of the FBI's old technology and business procedures.
A week before scheduled date of the of the Oklahoma City bomber FBI revealed that it had not disclosed over 700
documents to the defense attorneys. The FBI had simply forgotten to send materials and in many cases had lost evidence.
The legal process was thrown into turmoil, a stay of execution of the bomber was granted. An independent investigation
showed that the combination of the old computer system and manual processes were to blame.
FBI Sentinel Project

29
2001
FBI came under severe criticism
after several legal processes went
to turmoil. Investigation shown
the root of the problem was
combination of old computer
system and manual processes. Virtual Case File system (VCF)
VCF project was introduced to
overcome the problem, it was a
massive waterfall contract of
$379m. Grand design being
drawn up before work would start
on the development. Testing
would be carried out at the end,
and the whole system would go
live at once
FBI Sentinel Project
source: Agile Project Management for Government Case study: The Success of the FBI Sentinel Project

30
379
MILLIONS
24
MONTHS
Development Time Management FrameworkBudget
Attempt #1
2001
WATERFALL

31
9/11
Growing pressure to release the
project faster. Additional $78m
investment was forked to speed
up delivery by 6 months with
expected deployment at
December 2002.
Mid 2002
The classic symptoms of waterfall
project failure started to reveal
themselves. Project plans were
found to be unrealistic, and the
oversight of project spend was
inadequate.Post 2002
Work continued, and each year
the deadline was put back by
another 12 months. Every year a
new project executive was
appointed
Project Cancelled
In 2005 Project was finally
canceled.

32
425
MILLIONS
36
MONTHS
Attempt #2
2006
WATERFALL

33
Sentinel
Pursued the line of thought that if
more detail had been planned
upfront, with a more strict set of
waterfall processes, then failure
would not have occurred.
2006
Lockheed Martin was appointed
to take Sentinel project to be
completed by 2009, With total
$425m budget this time, over
$120m was allocated for the FBI
to oversight the work.Problem Arise
Phase one was a failure, 2 months
late, 57 critical features not
delivered, the system is practically
unusable. Despite this Lockheed
Martin still getting paid 100% for
the phase one. Along with it, the
Audit reports somehow
continued to be optimistic.
Dec 2008
Chad Fulgham was appointed as
the new CIO. He now planned for
outputs every 3-6 months. He
sees that it is very risky if phase
two was to be delivered next
year.

34
Phase Two Slipped
The planned end-date of phase
two slipped, the cost increased by
$18m. Then the new system
needed faster network, that is
another $39m need to be forked.
Inexperience PM
The $120m budget was spent on
inexperience PM with general
administrative backgrounds that
has no background of technology
development. Their reports are
detailed and full of statistics, but
never report a problem even
when the project was out of
control.
Dec 2009
As late as December 2009 the
FBI was still “expecting to provide
capabilities to users sooner than
originally planned”. However, the
more difficult tasks were left to
the end. Important tasks such as
the migration processes, were left
until the final segment. Migration
was known to be a key problem.
and when delivered in 2010, they
were still not adequate.
Phase Two Stopped
On March 3 FBI decide to reject
all deliverables of final segment of
phase two. Lockheed Martin was
ordered to stopped the
development until the problem
resolved. By July 2010 FBI issued
complete stop-work order.

35
An independent report estimated that completing Sentinel
under the current development approach would cost at
least an additional $351m on top of the $405m already
spent, and take another six years.

36
Agile To The Rescue
In September 2010 FBI announce
that it would take direct
management of the development
of Sentinel using Agile project
approach. Trimming The Unnecessary
The existing requirements were
analyzed, prioritized, and
sequenced to focus on the most
valuable requirements. The team
also reduced from 125 to a team
of 55. The original, monolithic
requirements document was
modularized into 670 separate
user stories. The team prioritized
each user story in a product
backlog.
Scrum Framework
21 sprints were planned to
develop all the user stories. The
10-day sprints kept the danger of
uncontrolled changes to what the
FBI called “just 9 days of risk”.
Previously, arguments over
change control and scope creep
took up much more time and
effort than that. At the end of
every sprint, all testing had to be
complete. The software had to be
demonstrated to project
stakeholders.
Thriving
By the end of 2011, only 52% of
the $32.6m budget had been
spent to build 88% of the system.

37
114
MILLIONS
36
MONTHS
Attempt #3
2009
AGILE

38
June 2012
revised technical targets had
been met, and two releases had
been achieved. Agents were now
using the system on real cases.
13,268 agents created 623
documents and made 92,546
searches in the first quarter 2012.
Operational Capability was
achieved in May 2012.
2013
Final user of ACS logs off.

39
9 Agile Leadership Behavior Takeaway
Harness changeSatisfy the customer Be incremental
Create trust through leadership
and process : ‘Light-Tight’ discipline
Encourage face to face
conversation
Get business & tech guy
together
Set targets and reward real
progress towards a working solution
Pursue simplicity
not complexity
Give the team the space
they need to excel

40
“Agile is not just a method or a process, it’s a way of
being. You don’t do Agile. You are Agile. The FBI has
arranged to loan their Scrum Master to other teams to
get them trained. Increased transparency has kept
stakeholders in sync. Further, stakeholders would
modify their expectations, based on the increased
visibility of the process.” ― Jack Israel (Former VCF CTO)

41
Agile Executives
source: http://www.allaboutagile.com/10-things-agile-executives-need-to-do-differently/

42
Organizational Change
PeopleMindset Tools / Framework
Managers StaffsExecutives

43
Product vs Project
Cost Allocated OwnershipTime Limit

COFFEE BREAK

45
Scrum /skrʌm/ noun
A framework within which people can address
complex adaptive problems, while
productively and creatively delivering
products of the highest possible value.

46
Scrum
Complex Product
Scrum is used for developing and sustaining complex
products.
3 Pillars
Adaptation, transparency, inspection uphold empirical
process control.
Scrum Elements
Scrum consist of Scrum team and their associated roles,
events, artifacts, and rules.
Framework
Scrum is an Agile framework, its not a methodology.
Empiricism
Scrum is founded on empiricism that asserts knowledge
comes from what is know.
Iterative & Incremental
Through iterative and incremental approach, Scrum optimize
predictability and control risk.
Scrum Value
Commitment, courage, focus, openness and respect are
embodied and lived by the Scrum Team

47
Complex Product?
source: http://scrumreferencecard.com/

48
3 Pillars
Transparency, inspection, and
adaptation.
Scrum Value
commitment, courage, focus,
openness and respect.
Empiricism
Asserts that knowledge comes
from experience and making
decisions based on what is
known.
Scrum Value
Successful use of Scrum
depends on people becoming
more proficient in living
these five values. When the
values of commitment,
courage, focus, openness and
respect are embodied and
lived by the Scrum Team, the
Scrum pillars of transparency,
inspection, and adaptation
come to life and build trust for
everyone. The Scrum Team
members learn and explore
those values as they work
with the Scrum events, roles
and artifacts.
EmpiricismThe key value that uphold empiricism

49
Long product development cycles, and a mismatch between a product’s business
requirement and the actual resulting implementation have been the classic problem
found in almost every software development. From the multi-billion FBI Sentinel
project to simple web application, face the very same problem.
This illustration explains such mismatched expectations, and the consequence of
long development cycles. For anyone who has been working in the software
development industry for a while, you would probably have gone through the hell of
the typical waterfall development approach. With an outcome where everyone in
the team is demoralized and where you end up with a bunch less-than-happy
customers – an unfortunate, dysfunctional outcome.
Shorter development cycles (called “sprints”) of 2 to 4 weeks and daily team
meetings known as “scrums” allow the product team, the product owner and the
customers/stakeholders to regularly review the incremental improvements made by
the team in each sprint. This narrows the expectations gap significantly and the
increased communication level between the product team and the stakeholders
reinforces a shared vision for each product increment made.
Why Scrum?Why Agile Development?
source: https://calvinx.com/2014/05/22/why-scrum-why-agile-development/

50
“Customers know exactly what they want.” ― another
statement from the same realm as movies: fiction

51
VS
Waterfall Scrum

52
Iterative & Incremental
source: http://itsadeliverything.com/

53
Roles
The roles of associated
Scrum Team members.
Events
Event in Scrum is a
formal opportunity to
inspect and adapt
something.
Artifacts
Product backlog,
Increment, Sprint
backlog.
Scrum Team
Product owner, Scrum
master, Development
team
Scrum ElementsScrum consist of these five elements
Rules
The rules of Scrum
binds together the
events, roles, and
artifacts.

54
Scrum Team
source: https://www.rockstart.com/

55
Faster actions and decisions – However capable and experienced the team leader, soon he becomes a bottleneck in speedy decisions &
actions. This is especially true where the team members themselves are expected to take on the spot actions or decisions since they are
best aware of the current situation.
Individual and team development – Self-organization takes away the protective umbrella provided by the team leader and forces the
individuals and the team to take greater responsibility and ownership of their work. In such an environment, team members understand
which skills & knowledge they need to acquire and go about on their own doing so. They also benefit from the support provided by their
peers. I have seen both the members as well as the teams rapidly mature by facing the challenges, sort of baptism by fire.
Redistribution of work between leader and the team – In a command & control culture, a typical team leader spends most of his time
planning & tracking the work of his sub-ordinates. As a result, he is left with very little time & attention to devote to the long term needs of
the team and its members. As the team becomes more & more self-organized, plenty of planning & tracking tasks are taken up by the team.
As a result, the team leader now has lot more time on his hand to engage in activities which do justice to his experience exposure and
maturity.
Self-OrganizationSelf-organizing teams choose how best to accomplish their work
Use of full human potential – People have lot of potential of which only a fraction normally gets used in a command and control culture.
When a team is self-organized, there are lot more opportunities to explore hidden or unused talents of its members.
source: https://www.agilealliance.org/

Have right people on
the team
Led within, not
managed
Understand team
goals
Communicate and
collaborate
continuously
Accountable for their
results

57
Scrum Events

58
Common PracticesScrum don’t define agile practices & technique
Scrum XP

59
Forming Storming Norming Performing
High Performance TeamThey don’t shape in a day

60
Quality Scrum Optimize
Flexibility ProductivityCreativity

61
THANK YOU

63
Scrum Team
Scrum Master Development TeamProduct Owner

64
Scrum Team

65
Product OwnerThe one person driving the product
Clearly expressing Product Backlog items,
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.
Product Owner is a person
responsible for maximizing the
value of the product and the
work of the development team
(Product Backlog and
determination of priorities).
Ensuring the Development Team understands items in the Product Backlog to the level
needed.

66
Development TeamWhere done product is produced
Consist of 3 – 9 members.
They are self-organizing. No one (not even the Scrum Master) tells the Development Team
how to turn Product Backlog into Increments of potentially releasable functionality.
Development Teams are cross-functional, with all of the skills as a team necessary to
create a product Increment.
Scrum recognizes no titles for Development Team members other than Developer,
regardless of the work being performed by the person.
Development team consist of
professionals who do the work
for delivering potentially
releasable Increment of “Done”
product at the end of each
Sprint. Self-organizing, cross-
functional.
Scrum recognizes no sub-teams in the Development Team, regardless of particular
domains that need to be addressed like testing or business analysis.
Individual Development Team members may have specialized skills and areas of focus, but
accountability belongs to the Development Team as a whole.

67
Scrum MasterThe servant leader leading the pact
The Scrum Master is a servant-leader for the Scrum Team.
Ensuring the Scrum is understood and enacted.
Ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.
Helps people outside the Scrum Team understand which of their interactions with the
Scrum Team are helpful and which aren’t, to maximize the value created by the Scrum
Team.
Scrum Master is a person
ensuring that Scrum is
understood and enacted. Sets
up meetings and monitors
everything.

68
Scrum Master to Product Owner
Finding techniques for effective Product Backlog management.
Helping the Scrum Team understand the need for clear and concise Product Backlog
items.
Understanding product planning in an empirical environment.
Ensuring the Product Owner knows how to arrange the Product Backlog to maximize
value.
Understanding and practicing agility.
Facilitating Scrum events as requested or needed.

69
Scrum Master 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.
Facilitating Scrum events as requested or needed.
Coaching the Development Team in organizational environments in which Scrum is not
yet fully adopted and understood.

70
Scrum Master to Development Team
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.
Working with other Scrum Masters to increase the effectiveness of the application of
Scrum in the organization.

71
Jakarta Tech CityWhere creative people build their dreams
Tech City where developers live, shape mini Jakarta to be the dream
city for smart people.
Vision
Population
Milestone 1
Milestone 2
3 Type of Population Inventor, Investor, Common Residence
Minimal Infrastructure for the Inventors to work and meet the
Investor.
Higher Quality of Service provide more comfort for work and
leisure.
Milestone 3
Scaling Up make sure our mini Jakarta can host more people and
produce more Inventors.

72
Lets Play Lego!Iterate and build the city
3 Minutes of planning what to build and how to build your city.Planning
Sprint
Review
Retrospect
7 Minutes of exciting playing games, catching up with the time limit,
construct your city, make it happen.
5 Minutes of measuring your great effort doing the exercise, and get
you ready for the next iteration.
5 Minutes of team self introspection, what went good or bad, and
how to improve.

74

75
Scrum Events

76
All events are time-boxed events, such that every event has a maximum duration.
Sprint duration is fixed and cannot be shortened or lengthened.
There are Sprint Planning, Daily Scrum, Sprint Review, Spring Retrospective, and Product Backlog
Refinement.
Scrum Events
Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal
opportunity to inspect and adapt.
Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect
and adapt.

77
Each Sprint may be considered a project with no more than a one-month horizon.
Sprint results “Done”, useable, and potentially releasable product Increment.
Sprints best have consistent durations throughout a development effort.
Sprints
A new Sprint starts immediately after the conclusion of the previous Sprint.
Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review,
and the Sprint Retrospective.
Quality goals do not decrease, No changes are made that would endanger the Sprint Goal.
Scope may be clarified and re-negotiated between the Product Owner and Development.
A Sprint can be cancelled before the Sprint time-box is over. Only by the Product Owner.

78
The work to be performed in the Sprint is planned at the Sprint Planning.
This plan is created by the collaborative work of the entire Scrum Team.
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint.
Sprint Planning
What can be delivered in the Increment resulting from the upcoming Sprint?
How will the work needed to deliver the Increment be achieved?
This is where Sprint Goal is crafted. The Sprint Goal is an objective set for the Sprint that can be met
through the implementation of Product Backlog.

79
Product Backlog vs Sprint Backlog

80
15-minute time-boxed event for the Development Team to inspect and adapt.
Development team answers 3 questions for themselves :
What did I do yesterday that helped the Development Team meet the Sprint Goal?
Daily Scrum
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me from meeting the Sprint Goal?

81
Walking The Board to The Rescue

82
Four-hour time-boxed meeting for one-month Sprints.
Attendees include the Scrum Team and key stakeholders invited by the Product Owner.
During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint,
attendees collaborate on the next things that could be done to optimize value.
Sprint Review
Development Team demonstrates the work that it has “Done” and answers about the Increment.
The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates
based on progress to date (if needed).
The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items
for the next Sprint.
Informal meeting, not a status meeting, intended to elicit feedback and foster collaboration.

83
Three-hour time-boxed meeting for one-month Sprints.
Opportunity for the Scrum Team to inspect itself and create a plan for improvements.
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.
Sprint Retrospective
Inspect how the last Sprint went with regards to people, relationships, process, and tools.
Identify and order the major items that went well and potential improvements.
Create a plan for implementing improvements to the way the Scrum Team does its work.

84
Informal event that covers the refinement of the product backlog.
Scrum Team decides how and when refinement is done.
Refinement usually consumes no more than 10% of the capacity of the Development Team.
Product Backlog Refinement
Increase visibility of product backlog that were likely to make it into the next sprint.

85
Scrum Artifacts
Sprint Backlog IncrementProduct Backlog

86
Scrum’s artifacts represent work or value.
Provide transparency and opportunities for inspection and adaptation.
Maximize transparency of key information so that everybody has the same understanding of the artifact.
Artifacts?

87
The single source of requirements for any changes to be made to the product.
The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes.
Product Backlog
Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s
discretion.
Higher ordered Product Backlog items are usually clearer, more detailed, more precise estimates and more
likely to be included in the next Sprint than lower ordered ones.
The Development Team is responsible for all estimates.

88
At any point in time, the total work remaining to reach a goal can be summed.
The Product Owner tracks this total work remaining at least every Sprint Review.
The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess
progress toward completing projected work by the desired time for the goal.
Monitoring Progress Toward A Goal
This information is made transparent to all stakeholders.
Various projective practices upon trending have been used to forecast progress, like burndowns, burn-ups,
or cumulative flows. These have proven useful.
However, these do not replace the importance of empiricism. In complex environments, what will happen is
unknown. Only what has happened may be used for forward-looking decision-making.

89
Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the
product.
Is a forecast by the Development Team about what functionality will next Sprint results and the work
needed to deliver that functionality into a “Done” Increment.
The Development Team modifies the Sprint Backlog throughout the Sprint.
This emergence occurs as the Development Team works through the plan and learns more about the work
needed to achieve the Sprint Goal.
Belongs solely to the Development Team.

90
At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed.
The Development Team tracks this total work remaining at least for every Daily Scrum to project the
likelihood of achieving the Sprint Goal.
By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.
Monitoring Sprint Progress

91
source: https://confluence.atlassian.com/
Burn-down Chart

92
Cone of Uncertainty
source: http://www.agilenutshell.com/

93
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the
increments of all previous Sprints.
New Increment must meet the Scrum Team’s definition of “Done”.
Must be in useable condition regardless of whether the Product Owner decides to actually release it.
Increment

94
When a Product Backlog item or an Increment is described as “Done”, everyone must understand what
“Done” means.
Scrum Team must have a shared understanding of what it means for work to be “Done”.
Guides the Development Team in knowing how many Product Backlog items it can select during a Sprint
Planning.
Definition of “Done”
As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent
criteria for higher quality.

95
Definition of “Done” Example
source: https://www.scruminc.com/definition-of-done/

96
Some More Example of DoD
source: http://www.allaboutagile.com/definition-of-done-10-point-checklist/
Code commented, checked in and run against current version in source control.
Peer reviewed (or produced with pair programming) and meeting development standards.
Builds without errors.
Unit tests written and passing.
Deployed to system test environment and passed system tests.
Passed UAT (User Acceptance Testing) and signed off as meeting requirements.
Any build/deployment/configuration changes implemented/documented/communicated.
Relevant documentation/diagrams produced and/or updated.
Code produced (all ‘to do’ items in code completed).
Remaining hours for task set to zero and task closed.

98
EXAM TIME!

99
Recommended Books & Other Resources
The Scrum Guide - Jeff Sutherland & Ken Schwaber
Scrum – A Pocket Guide - Gunther Verheyen
Manajemen Modern dengan Scrum - Joshua Partogi
Scrum.org Open Assessment
mlapshin PSM I Quiz
testtakeronline PSM I Study Guide
Development That Pays (YouTube Channel) - Gary Straughan
Agile Indonesia Meetup Community

100
THANK YOU

PMO & Scrum Master | PRINCE2® | PSM™ I
+62817610162 | ichsan.rahardianto@gmail.com
https://www.linkedin.com/in/irahardianto/
@irahardianto

Scrum, The Agile Framework

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Scrum, The Agile Framework

Similar to Scrum, The Agile Framework (20)

Recently uploaded

Recently uploaded (19)

Scrum, The Agile Framework