Leveraging Agile Project Management with Scrum

Leveraging
AGILE Project Management
with SCRUM
IImage: hdwallpapers
Facilitated by Goutama Bachtiar
v3.6.1 as of October 2018

Workshop Agenda
3
 Module 1: A Sneak-Peek on Waterfall Model
 Module 2: Introduction to SCRUM Framework
 Module 3: Scrum International Certifications
 Module 4: Roles & Artifacts in SCRUM
 Module 5: Requirements Management
 Module 6: Project Estimation and Planning
 Module 7: Project Execution
 Module 8: Project Monitoring and Controlling
October 2018Agile with Scrum

Workshop Agenda (cont’d)
4
 Module 9: Scrum Adoption
 Module 10: Key Challenges
 Module 11: Key Success Factors
 Module 12: Kanban and TDD Framework
 Module 13: Scrum Documentation
 Module 14: Scrum Tools and Software
October 2018Agile with Scrum

5
• Please kindly set all mobile phones etc on silent mode
• Feel free to interrupt my presentation to ask questions at
any time
• In the end, there is a final Q&A session for deeper
concerns
• Time is slightly relative and I own the clock ☺
• Do actively participate! And don’t forget to have fun!
October 2018 Agile with Scrum
Ground Rules

6
A Sneak-Peek on Waterfall Model
Module 1

7
*All Registered Trademarks and Service Marks are the property of the Project Management Institute
PMBOK 5 Process Groups and Knowledge Areas
2018 Agile & Scrum

8
PMBOK 5 Process Groups and Knowledge Areas (cont’d)
2018 Agile & Scrum

Advantages of Waterfall Model
9
1. Simple and easy to understand
and use
2. Easy to manage due to rigidity of
the model
3. Phases are executed and
completed one at a time, no
overlaps
4. Works well in cases of non-
complex projects

10
1. Don’t get to see the end-product until the end of the life-
cycle.
2. Challenging to trace back to earlier phases and fix issues;
incurs huge cost and risk
3. Managing changing requirements during the life-cycle
4. Loaded with risk and uncertainty
5. Does not suit large/complex/integrated projects that have
evolving requirements
Challenges in Waterfall Model

11
No Process Input Output
1
Develop
Project Charter
1. Project Statement of Work
1. Project Charter
2. Business Case
3. Agreement
4. Enterprise Environmental Factors
5. Organizational Process Assets
2
Identify
Stakeholders
1. Project Charter
1. Stakeholder Register2. Procurement Documents
3
Develop Project
Management Plan
1. Project Charter
1. Project Management Plan
2. Outputs from other Planning Processes
4 Plan Scope Management
1. Scope Management Plan
2. Project Charter
2. Requirements Management Plan
5 Collect Requirements
1. Requirements Documentations2. Requirements Management Plan
3. Stakeholder Management Plan
4. Project Charter
2. Requirements Traceability Matrix
5. Stakeholder Register
6 Define Scope
1. Project Scope Statement
2. Project Charter
3. Requirements Documentation
2. Project Document Updates
7 Create WBS
1. Scope Baseline
3. Requirements Documentation
2. Project Document Updates4. Enterprise Environmental Factors
PMBOK 5 Inputs/Outputs and Processes
2018 Agile & Scrum

12
8 Plan Schedule Management
1. Schedule Management Plan
2. Project Charter
9 Define Activities
1. Schedule Management Plan 1. Activity List
2. Scope Baseline 2. Activity Attributes
3. Enterprise Environmental Factors 3. Milestone List
10 Sequence Activities
1. Project Schedule Network Diagram
2. Activity List
3. Activity Attributes
4. Milestone List
11 Estimate Activity Resources
1. Schedule Management Plan 1. Activity Resource Requirements
2. Activity List
2. Resource Breakdown Structure
4. Resource Calendars
5. Risk Register
6. Activity Cost Estimates
3. Project Documents Updates
PMBOK 5 Inputs/Outputs and Processes (cont’d)
2018 Agile & Scrum

13
12 Estimate Activity Durations
1. Activity Duration Estimates
2. Activity List
4. Activity Resource Requirements
7. Risk Register
13 Develop Schedule
1. Schedule Management Plan 1. Schedule Baseline
2. Activity List
2. Project Schedule4. Activity Resource Requirements
5. Project Schedule Network Diagram
6. Resource Calendars 3. Schedule Data
7. Activity Duration Estimates
8. Project Scope Statement 4. Project Calendars
9. Risk Register
10. Project Staff Assignments 5. Project Management Plan Updates
12. Enterprise Environmental Factors 6. Project Document Updates
14 Plan Cost Management
1. Cost Management Plan2. Project Charter
2018 Agile & Scrum

14
15 Estimate Costs
1. Cost Management Plan
2. Human Resource Management Plan
3. Scope Baseline
2. Basis of Estimates
4. Project Schedule
5. Risk Register
3. Project Documents Updates6. Enterprise Environmental Factors
16 Determine Budget
1. Cost Baseline2. Scope Baseline
4. Basis of Estimates
2. Project Funding Requirements5. Project Schedule
7. Risk Register
3. Project Document Updates8. Agreements
17 Plan Quality Management
1. Project Management Plan 1. Quality Management Plan
2. Stakeholder Register 2. Process Improvement Plan
3. Risk Register 3. Quality Metrics
4. Requirements Documentation 4. Quality Checklists
2018 Agile & Scrum

15
18
Plan Human Resource
Management
2. Activity Resource Requirements
19
Plan Communications
Management
1. Communication Management Plan
20 Plan Risk Management
1. Risk Management Plan
2. Project Charter
21 Identify Risks
1. Risk Mgmt. Plan 2. Cost Mgmt. Plan
1. Risk Register
3. Schedule Mgmt. Plan 4. Qual. Mgmt. Plan
5. HR Mgmt. Plan 6. Scope Baseline
7. Activity Cost Est. 8. Activity Duration Est.
10. Project Documents
11. Procurement Documents
2018 Agile & Scrum

16
22
Perform Qualitative
Risk Analysis
2. Scope Baseline
3. Risk Register
23
Perform Quantitative
Risk Analysis
4. Risk Register
24 Plan Risk Responses
1. Risk Management Plan 1. Project Management Plan Updates
2. Risk Register 2. Project Document Updates
25
Plan Procurement
Management
1. Project Management Plan 1. Procurement Management Plan
2. Requirements Documentation 2. Procurement Statement of Work
3. Risk Register 3. Procurement Documents
4. Activity Resource Requirements 4. Source Selection Criteria
5. Project Schedule 5. Make-or-buy Decisions
6. Change Requests
2018 Agile & Scrum

17
26 Plan Stakeholder Management
1. Stakeholder Management Plan
27
Direct and Manage
Project Work
1. Project Management Plan 1. Deliverables
2. Approved Change Requests 2. Work Performance Data
3. Enterprise Environmental Factors 3. Change Requests
4. Organizational Process Assets 4. Project Management Plan Updates
28 Perform Quality Assurance
1. Quality Management Plan 1. Change Requests
2. Process Improvement Plan 2. Project Management Plan Updates
3. Quality Metrics 3. Project Document Updates
4. Quality Control Measurements
4. Organizational Process Assets Updates
29 Acquire Project Team
1. Human Resource Management Plan 1. Project Staff Assignments
2. Enterprise Environmental Factors 2. Resource Calendars
30 Develop Project Team
1. Human Resource Management Plan 1. Team Performance Assessments
2. Project Staff Assignments
2. Enterprise Environmental Factors Updates
2018 Agile & Scrum

18
31 Manage Project Team
1. Change Requests
2. Project Staff Assignments
3. Team Performance Assessments 2. Project Management Plan Updates
4. Issue Log 3. Project Document Updates
5. Work Performance Reports 4. Enterprise Environmental Factors Updates
6. Organizational Process Assets 5. Organizational Process Assets Updates
32 Manage Communications
1. Communication Management Plan 1. Project Communications
2. Work Performance Reports 2. Project Management Plan Updates
33 Conduct Procurements
1. Procurement Management Plan 1. Selected Sellers
2. Procurement Documents 2. Agreements
3. Source Selection Criteria 3. Resource Calendar
4. Seller Proposals 4. Change Requests
5. Project Management Plan Updates
6. Make-or-buy Decisions
7. Procurement Statement of Work
34
Manage Stakeholder
Engagement
1. Stakeholder Management Plan 1. Issue Log
2. Communications Management Plan 2. Change Requests
3. Change Log 3. Project Management Plan Updates
4. Organizational Process Assets 4. Project Document Updates
5. Organizational Process Asset Updates
2018 Agile & Scrum

19
35
Monitor and Control
Project Work
1. Change Requests
2. Schedule Forecasts
3. Cost Forecasts 2. Work Performance Reports
4. Validated Changes 3. Project Management Plan Updates
5. Work Performance Information 4. Project Document Updates
36
Perform Integrated
Change Control
1. Project Management Plan 1. Approved Change Requests
2. Work Performance Reports 2. Change Log
3. Change Requests 3. Project Management Plan Updates
37 Validate Scope
1. Project Management Plan 1. Accepted Deliverables
2. Requirements Documentations 2. Change Requests
3. Requirements Traceability Matrix 3. Work Performance Information
4. Verified Deliverables 4. Project Document Updates
5. Work Performance Data
38 Control Scope
1. Project Management Plan 1. Work Performance Information
2. Requirements Documentation 2. Change Requests
3. Requirements Traceability Matrix 3. Project Management Plan Updates
4. Work Performance Data 4. Project Document Updates
2018 Agile & Scrum

20
39 Control Schedule
1. Work Performance Information
2. Project Schedule
3. Work Performance Data 2. Schedule Forecasts
4. Project Calendars 3. Change Requests
5. Schedule Data 4. Project Management Plan Updates
40 Control Costs
2. Project Funding Requirements 2. Cost Forecasts
3. Work Performance Information 3. Change Requests
41 Control Quality
1. Project Management Plan 1. Quality Control Measurements
2. Quality Metrics 2. Validated Changes
3. Quality Checklists 3. Verified Deliverables
4. Work Performance Data 4. Work Performance Information
5. Approved Change Requests 5. Change Requests
6. Deliverables 6. Project Management Plan Updates
7. Project Documents 7. Project Document Updates
8. Organizational Process Assets 8. Organizational Process Asset Updates
2018 Agile & Scrum

21
42 Control Communications
2. Change Requests2. Project Communications
3. Issue Log 3. Project Management Plan Updates
4. Work Performance Data 4. Project Document Updates
43 Control Risks
2. Risk Register 2. Change Requests
3. Work Performance Data 3. Project Management Plan Updates
4. Work Performance Reports 4. Project Document Updates
44 Control Procurements
2. Procurement Documents 2. Change Requests
3. Agreements 3. Project Management Plan Updates
4. Approved Change Requests 4. Project Document Updates
5. Work Performance Reports 5. Organizational Process Assets Updates
6. Work Performance Data
45
Control Stakeholder
Engagement
2. Issue Log 2. Change Requests
3. Work Performance Data 3. Project Management Plan Updates
4. Project Documents 4. Project Document Updates
2018 Agile & Scrum

22
46 Close Project or Phase
1. Project Management Plan 1. Final Product, Service or Result Transition
2. Accepted Deliverables 2. Organizational Process Assets Updates
47 Close Procurements
1. Project Management Plan 1. Closed Procurements
2. Procurement Documents 2. Organizational Process Assets Updates
2018 Agile & Scrum

23
Introduction to SCRUM Framework
Module 2

24
• An alternative to mainstream/waterfall project management
• Focus on customer/user satisfaction
• Adapts well to deal with uncertainties and changing situations
• Delivers in increments following an iterative process
• Continuous attention to all aspects of delivery – Planning, Design,
Delivery, Quality
• Empowers team to make decisions
• Follows an inspect-and-adapt approach
Understanding Agile PM

25
Incrementing calls for a fully formed idea
“incrementing” builds a bit at a time
© Jeff Patton, all rights reserved, www.AgileProductDesign.com
Iterating allows you to move from vague idea to
realization.
“iterating” builds a rough version, validates it,
then slowly builds up quality
It is not an iteration if you only do it once
Iterative vs Incremental PM

26
© Jeff Patton, all rights reserved, www.AgileProductDesign.com
The increment adds
completely new features,
based on user stories,
hence expanding the
scope of the functionality
offered – that makes it
incremental.
But each increment is
also likely to refine
existing functionality –
that makes it iterative.
Agile and Scrum is Both Incremental and Iterative

• Waterfall-Plan Driven Approach: Scope remains fixed, while Resources and Schedules are adjusted
• Agile-Value Driven Approach: Scope is adjusted while Resources and Schedules are fixed
Waterfall-Plan Driven
Agile-Value Driven
Fixed: Features Resources Schedule
Variable: Resources Schedule Features
Paradigm Shift

29
Agile – Value Proposition

30
Agile – Value Proposition (cont’d)

31
• Project will be staffed with qualified & disciplined individuals.
• Interfaces are well-defined.
• Deliverables can be reasonably distributed in work packets
achievable in 2 - 4 week periods.
• Responsiveness to customer requests defines success.
• Customer or customer representative is available for close
collaboration throughout the project.
• Scope can be adjusted to fit schedule.
When to Use Agile?

32
• Customer is able to reprioritize and add requirements as they
progress.
• Work is ground-breaking with steps defined by progress resulting in
estimates that are not expected to be reliable.
• Incremental results have significant value.
• Process is by nature iterative, allowing for cumulative results
though sprints, and for overlapping planning for the next sprint
while work takes place in the current sprint.
When to Use Agile? (cont’d)

Relationship between Values, Principles and Practices
Respond to
change

Agile Manifesto (http://agilemanifesto.org/)
34
We are uncovering better ways of developing software by doing it and helping
others do it. Through this work we have come to value:
That is, while there is value in the items on the right, we value the items on the
left more.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Agile Principles
2018 Agile & Scrum 35
Lists 12 principles to guide teams on how to execute with agility:
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 preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
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.

Agile Principles (cont’d)
8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
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 behaviour
accordingly.

Agile Framework/Methodology
37
Methodology Notes
Scrum Ken Schwaber, Jeff Sutherland; Process skeleton; Most widely used in industry. It is revolutionary in nature
XP (Extreme
Programming)
Kent Beck; More prescriptive, processes and technical practices (eg: Pair Programming, TDD, Simple Design,
Collective Code Ownership)
Lean Iterative methodology originally developed by Mary and Tom Poppendieck. Lean Software Development owes
much of its principles and practices to the Lean Enterprise movement and the practices of companies like
Toyota. Focus is on delivering value, efficiency . Is based on 7 key principles
Kanban Methodology David Anderson, Andy Carmichael Uses Kanban to implement full life cycle. Has 6 principled and practices
each. It is evolutionary in nature
Crystal Clear Alistair Cockburn; focus on people
Dynamic Systems
Development (DSDM)
Based on nine key principles that primarily revolve around business needs/value, active user involvement,
empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. Follows the MOSCOW
model for prioritization
Feature Driven
Development (FDD)
Originally developed and articulated by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul
Szego, Jon Kern and Stephen Palmer. Has 8 key practices (Developing by Feature Class Code Ownership,
Feature Team, Inspections, Frequent Releases etc..)

Advantages of Agile
• Change is embraced
With shorter planning cycles, it’s easy to accommodate and accept
changes at any time during the project. There is always an opportunity
to refine and reprioritize the backlog, letting teams introduce changes
to the project in a matter of weeks.
• End-goal can be unknown
Agile is very beneficial for projects where the end-goal is not clearly
defined. As the project progresses, the goals will come to light and
development can easily adapt to these evolving requirements.
• Faster, high-quality delivery
Breaking down the project into iterations (manageable units) allows the
team to focus on high-quality development, testing, and collaboration.
Conducting testing during each iteration means that bugs get identified
and solved more quickly. And this high-quality software can be
delivered faster with consistent, successive iterations.

Advantages of Agile (cont’d)
• Strong team interaction
It highlights the importance of frequent communication and face-
to-face interactions. Teams work together and people are able
to take responsibility and own parts of the projects.
• Customers are heard
Customers have many opportunities to see the work being
delivered, share their input, and have a real impact on the end
product. They can gain a sense of ownership by working so
closely with the project team.
• Continuous improvement
Agile projects encourage feedback from users and team
members throughout the whole project, so lessons learned are
used to improve future iterations.

Disadvantages of Agile
• Planning can be less concrete
It can sometimes be hard to pin down a solid delivery date. Because
Agile is based on time-boxed delivery and project managers are often
reprioritizing tasks, it’s possible that some items originally scheduled
for delivery may not be complete in time. And, additional sprints may
be added at any time in the project, adding to the overall timeline.
• Team must be knowledgeable
Agile teams are usually small, so team members must be highly skilled
in a variety of areas. They also must understand and feel comfortable
with the chosen Agile methodology.

Disadvantages of Agile (cont’d)
• Time commitment from developers
Agile is most successful when the development team is
completely dedicated to the project. Active involvement and
collaboration is required throughout the Agile process, which is
more time consuming than a traditional approach. It also means
that the developers need to commit to the entire duration of the
project.
• Documentation can be neglected
The Agile Manifesto prefers working software over
comprehensive documentation, so some team members may
feel like it’s less important to focus on documentation. While
comprehensive documentation on its own does not lead to
project success, Agile teams should find the right balance
between documentation and discussion.

Disadvantages of Agile (cont’d)
• Final product can be very different
The initial Agile project might not have a
definitive plan, so the final product can look
much different than what was initially
intended. Because Agile is so flexible, new
iterations may be added based on evolving
customer feedback, which can lead to a
very different final deliverable.

43
• A framework within which people can address complex adaptive
problems, while productively and creatively delivering products of the
highest possible value.
• Lightweight, Simple to understand, Difficult to master
• Empirical Process: Inspect, Adapt, Transparency
• I and I approach to optimize predictability and control risk
• Emphasis on Collaboration
• See change as opportunity
• A revolutionary approach
What is Scrum?

44
• Takeuchi and Nonaka – coined in The New Product
Development Game in 1986
• 1993 First Project Easel Corp by Jeff Sutherland, formalized
by Ken Schwaber and Jeff Sutherland in 1995
• 2002 Scrum Alliance formed
• It is now probably the fastest-growing approach to software
development globally
• Used in many Fortune 100 companies globally such as
Nokia, HP, EMC, GE, Google, SUN, Infosys, Wipro, IBM, and
Facebook, among others
Mike Cohn: An agile framework that allows us to focus on
delivering the highest business value in the shortest time”
Scrum Historical Perspectives

Product Backlog
Sprint Backlog
Sprint
Potentially shippable
Product Increment
Sprint Review and
Sprint Retrospective
Daily Scrum
Sprint Planning
Scrum Project Life Cycle

46
“Delivery
Early. Delivery
Often”
“Empower
your Teams”
“Inspect and
Adapt
5 Time-boxes
3 Artifacts
3 Roles
11 Techniques3 Key Tenets

Advantages of Scrum
• More transparency and project visibility
With daily stand-up meetings, the whole team knows who is doing
what, eliminating many misunderstandings and confusion. Issues are
identified in advance, allowing the team to resolve them before they
get out of hand.
• Increased team accountability
There is no project manager telling the Scrum Team what to do and
when. Instead, the team collectively decides what work they can
complete in each sprint. They all work together and help each other,
improving collaboration and empowering each team member to be
independent.

Advantages of Scrum (cont’d)
• Easy to accommodate changes
With short sprints and constant feedback, it’s easier to cope with and
accommodate changes. For example, if the team discovers a new user
story during one sprint, they can easily add that feature to the next
sprint during the backlog refinement meeting.
• Increased cost savings
Constant communication ensures the team is aware of all issues and
changes as soon as they arise, helping to lower expenses and
increase quality. By coding and testing features in smaller chunks,
there is continuous feedback and mistakes can be corrected early on,
before they get too expensive to fix.

Disadvantages of Scrum
• Risk of scope creep
Some Scrum projects can experience scope creep due to a lack of
specific end date. With no completion date, stakeholders may be
tempted to keep requesting additional functionality.
• Team requires experience and commitment
With defined roles and responsibilities, the team needs to be familiar
with Scrum principles to succeed. Because there are no defined roles
in the Scrum Team (everyone does everything), it requires team
members with technical experience. The team also needs to commit to
the daily Scrum meetings and to stay on the team for the duration of
the project.

Disadvantages of Scrum (cont’d)
• The wrong Scrum Master can ruin everything
The Scrum Master is very different from a project manager. The Scrum
Master does not have authority over the team; he or she needs to trust
the team they are managing and never tell them what to do. If the
Scrum Master tries to control the team, the project will fail.
• Poorly defined tasks can lead to inaccuracies
Project costs and timelines won’t be accurate if tasks are not well
defined. If the initial goals are unclear, planning becomes difficult and
sprints can take more time than originally estimated.

52
SCRUM International Certifications
Module 3

ScrumAlliance The Organization
• Founded in 2001
• The largest, most established and influential
professional membership (non profit) organization in
Agile community
• Having certified 450,000+ individuals worldwide.
• Offering 6 (six) certifications.
• Having 275 User Groups across the globe.
• Vision is to "Transform the World of Work.”
• Mission is to guide and inspire individuals, leaders, and
organizations with practices, principles, and values that
create workplaces that are joyful, prosperous, and
sustainable.
• In short, Scrum at the foundation of all our products,
services, and solutions.
532018 Agile & Scrum

ScrumAlliance Certifications

ScrumAlliance’s CSP Certification
Requirements
• Be a current holder of an active CSM, CSPO,
or CSD credential.
• Min. of 36 months of successful Agile/Scrum work
experience gained in the past 5 years implementing
Scrum inside organizations as team member, product
owner, ScrumMaster, or "Other."
• 70 SEUs from the past three years (Note: CSM (up to
16 SEUs), CSD (up to 24 SEUs), and/or CSPO (up to
16 SEUs)).
• Our CSD, CSM, or CSPO training can be 3+ years old.
• USD 100 nonrefundable application fee and USD 150
for certification approval fee. 572018 Agile & Scrum

(cont’d)
How to earn SEUs
• Category A: Scrum Alliance Scrum Gatherings
Up to 45 SEUs can be earned at a rate of one credit per hour of
participation in Scrum Alliance Global Gatherings, Scrum Alliance
Regional Gatherings, Scrum Coaching Retreats, and Scrum Alliance-
Sponsored Events, as well as in Scrum Alliance-endorsed User
Group events and activities (presenting, coaching, and attending
sessions).
• Category B: Scrum Alliance Courses or Coaching
Min. 14 SEUs required for this category.
Received training from CSM /CSPO/CSD/CST/REP or coaching by a
CEC.

(cont’d)
• Category C: Outside Events
Up to 15 SEUs and earned one credit per
hour of active participation.
Attended live Scrum/Agile or User Group
events or received Coaching/Mentoring
outside of Scrum Alliance.
• Category D: Volunteer Service
Up to 15 SEUs earned by providing non-
compensated, professional Scrum services.

(cont’d)
• Category E: Independent Learning
Up to 15 SEUs earned through various
independent learning activities (preparing/not
delivering presentations; authoring relevant
books/articles/blogs; watching a training video;
reading books.
• Category F: Other Collaborative Learning
Up to 15 SEUs earned through a variety of other
collaborative learning activities engaged in with
other Scrum practitioners e.g. attending
webinar, etc.

(cont’d)
Renewing CSP with SEUs
Required min. 40 SEUs
within two years.
No category limits.
Up to 90 days past our CSP
expiration date.
USD 250 renewal fee.
Membership:
http://membership.scrumallia
nce.org/?page=Membership
s

ScrumAlliance’s CSM Certification
• Certified
ScrumMaster®
• Requirements
– Enroll in-person,
two-day (16-hour)
CSM course from a
Scrum Alliance
Authorized Trainer
– Take online CSM
test (at least 24 out
of 35 Qs)

ScrumAlliance’s CSPO Certification
• Certified Scrum
Product Owner®
(CSPO)
• Requirements
–Attend an in-
person, two-day
CSPO course
taught by a
Certified Scrum
Trainer

ScrumAlliance’s CSD Certification
• Certified Scrum Developer (CSD)
• Requirements
– >= Five days of formal training taught by a Scrum
Alliance REP and a Scrum Alliance Authorized
Instructor.
– Passed the classroom-based assessment/exam.
– Two tracks
• Track 1
CSM course (2 days)
CSD “Agile Engineering Practices” technical course (3 days)
• Track 2
CSD Intro course (1 day)
CSD “Agile Engineering Practices” technical course (3 days)
CSD Technical Elective course (1 day)

ScrumAlliance’s CTC Certification
• Certified Team Coach (CTC)
• What CTC does?
– Works with Scrum teams, stakeholders, and
management to improve performance and outcomes.
– Provides coaching, facilitation, training, mentoring,
impediment management, and leadership in support
of collaboration, development consistency, and value
delivery across multiple teams and departments.
– Unlike a CSM, CTC works across multiple teams.
– Unlike a CEC, CTC focuses on a subset of an
organization in a project or program, or across
multiple teams.

ScrumAlliance’s CTC Certification
(cont’d)
• Requirements
– Active CSP designation.
– Demonstrate a minimum of 2 years and 1,000 hours
of Scrum coaching experience across a diversity of
teams.
– Demonstrate active engagement in, contribution to,
and leadership in the Scrum community over a
minimum of 2 years.
– Demonstrate a journey of learning through formal
and informal education and mentor relationships.
– Provide two different client recommendations and
one mentor recommendation to verify coaching
experience and skills.
– Complete a two-part application process that is both
quantitative and qualitative.

ScrumAlliance’s CEC Certification
• Certified Enterprise Coach (CEC)
• What CEC does?
– Coach organization towards Agile transformation.
– Experts in Scrum both theory and practice.
– Have in-depth understanding of practices and principles of
Scrum and real-world experience in actual Scrum organizations.
– Have deep experience in leadership coaching, organizational
transformation, and Agile practices at the enterprise level.
– Have had years of practice (successes and failures) in Scrum at
multiple levels of engagement at the leadership level.
– Must demonstrate experiences as organizational change agent
working across multiple team and organizational boundaries.

• Requirements
Experience
• I have held an active CSP designation for a minimum of 1 year.
• I have significant hands-on experience in at least one of the roles on a Scrum Team.
• I have coached in 3 or more organizations, departments, or programs.
• I have a minimum of 3 years and 2,000 hours of experience coaching at the
enterprise/organizational level or a combination of enterprise and multi-team level coaching.
• I have a diversity of coaching experiences that I can demonstrate using different client
engagement examples, and which include experience at the organizational level.
Knowledge
• I have formal and informal education about coaching and strong mentor relationships.
• I have a good working knowledge of Agile and Lean values, principles, and practices.
• I have helped individuals, teams, and leadership to understand and apply Agile and Lean
values, principles, and practices effectively.
• I understand the dynamics, patterns, and development of multi-level teams and how they
interact at the organizational level.
• I can clearly describe the difference between consulting and coaching and know when to apply
each.

(cont’d)
Professional Collaboration
• I can provide two different client recommendations and one mentor
recommendation to verify my coaching experience and skills.
• I have had active engagement in, contribution to, and leadership in, the
Scrum community over a minimum of 3 years
• I have participated in at least 5 private or public Scrum- or Agile-related
events and have contributed to some of these as an organizer, presenter,
collaborator or facilitator.
Skills
• I have contributed to significant improvements in organizations or
departments through coaching techniques.
• I have helped organizations and teams beyond the basics of Scrum theory
and practice.
• I have enabled organizations to find their own solutions to business
problems through the application of Agile principles.
• I am familiar with, promote and embody the mindset of Servant
Leadership.
• I use a rich set of facilitation, training and coaching tools, and models.

Mapping SA Certs to Agile Team Roles

PMI ACP
• Stands for PMI Agile Certified Practitioner
• Spans across Agile methodology such as
Scrum, Kanban, Lean, extreme programming
(XP) and test-driven development (TDD).
• Requirements
– 2,000 hours of general project experience
working on teams.
– 1,500 hours working on agile project teams or
with agile methodologies.
– 21 training hours in agile practices.

PMI ACP (cont’d)
• Exam format: 120 multiple-
choice questions
• Exam duration: Three
hours.
• To maintain: 30
professional development
units (PDUs) in three
years.
• PMI member US$435, PMI
non-member US$495.

Professional Scrum Master
• From Scrum.org
• PSM I
• Fee: $150 per attempt
• Passing score: 85%
• Number of Questions: 80
• Time limit: 60 minutes
• Format: Multiple Choice, Multiple Answer and True/False
• Difficulty: Intermediate
• Language: English only
• Required course: None
• Recommended courses: Professional Scrum Foundations or Professional Scrum Master
• PSM Subject Areas
October 2018 Agile with Scrum 80

Professional Scrum Master (cont’d)
PSM II
• Fee: $250
• Difficulty: Advanced
• PSM II Subject Areas
• Recommended courses: Professional Scrum Master and Professional Scrum Master II
• Recommended Certification: PSM I
• Practice assessments: PSM I, PSPO I, PSD I, Scrum Open

Professional Scrum Master (cont’d)
PSM III
• Fee: $500
• Format: Combination of 34 Multiple Choice and essay
• PSM Subject Areas
• PSM II Subject Areas
• Recommended courses: Professional Scrum Master and Professional Scrum Master II
• Required assessment: PSM I (must pass) and PSM II
• Practice assessment: Scrum Open, Nexus Open, Developer Open and Product Owner Open.

Professional Scrum Product Owner
PSPO I
• PSPO Subject Areas
• Recommended course: Professional Scrum Product Owner
• Practice assessments: Scrum Open and Product Owner Open

Professional Scrum Product Owner (cont’d)
PSPO II
• Fee: $500
• Format: Multiple Choice and essay
• PSPO Subject Areas
• Recommended course: Professional Scrum Product Owner
• Ways to Learn More to help you prepare
• Required assessment: PSPO I (must pass)
• Practice assessments: Scrum Open and Product Owner Open

Professional Scrum Developer
PSD
• Scrum Developer Subject Areas
• Recommended course: Professional Scrum Developer
• Practice assessments: Scrum Open and Scrum Developer Open

Professional Agile Leadership
PAL
• PAL Subject Areas
• Recommended course: Professional Agile Leadership Essentials (PAL-E)
• Practice assessments: Agile Leadership Open, Scrum Open

Professional Scrum with Kanban
PSK
• PSK Subject Areas
• Recommended course: Professional Scrum with Kanban
• Practice assessments: Scrum with Kanban Open

Scaled Professional Scrum
SPS
• Fee: $250
• Passing score: 85% or greater
• Format: Multiple Choice, Multiple Answer, and True/False
• Related Guide: Nexus Guide
• Recommended course: Scaled Professional Scrum Workshop
• Practice Assessment: Nexus Open

89
Roles and Artifacts in SCRUM
Module 4

90
Product Owner
Scrum Master Scrum Team
Stakeholders &
Users
Customer
voice who
establishes
vision,
prioritizes the
work and
defines
success
criteria
The servant-leader
who empowers the
team, facilitates the
process, and
removes
impediments, if any
People who
deliver
customer/
user value
Individual, groups
and organizations
that have interests
and attain the
benefits from the
project deliverable
Roles in Scrum

Product Owner
• Owns vision for the product to be
produced/released
• Represents client organization or
acts as principal interface to the
client
• Creates and maintains Product
Backlog
• Final decision maker on
prioritization of Product Backlog
items
• Provides support in removing
obstacles

Scrum Master
• Facilitates implementation of the process
• Ensure team lives by values and
practices
• Removes team’s constraints and
impediments
• Protects team from overcommitting
• Protects team from external disturbances
• Empowers team through Servant
Leadership
• Coaches team for successful
implementation
• Builds self-organizing teams
92

Scrum Team
• Constitutes of 3-9 individual
• Cross-functional team includes design,
coding, testing, and other resources
required for potentially shippable deliverable
• Takes responsibility to determine how to
best achieve product goals set by PO
• Plans and manages the project by working
in incremental and iterative manner
• Collaborates closely with PO and SM
• Inspects and Adapts through Daily Scrum
and Retrospective
• Assists PO to groom the backlog

Project
Manager and
Product
Owner in
SCRUM

95
Time-Boxed Event
For Sprints of 4
Weeks
For Sprints of 2
Weeks
For Sprints of 1
Week
Sprint Planning 1 Day Half-Day 2 Hours
Sprint 20 Days 10 Days 5 Days
Sprint Review Half-Day 2 Hours 1 Hours
Sprint Retrospective Half-Day 2 Hours 1 Hours
Daily Scrum 15 Minutes 15 Minutes 15 Minutes
These are the maximum durations of each timebox. Meetings may adjourn early if
the agenda is completed.
Duration of Timeboxes

96
• Product Backlog
• Sprint Backlog
• Incremental potential shippable product
• Burn Down Charts
• Burn Up Charts
Artifacts
Information Radiators
Artifacts and Information Radiators

97October 2018 Agile with Scrum

98
Requirements Management
Module 5

99
• Contains a broad list of descriptions of all required
features, wish-list items, etc.
• Prioritization by business value.
• It’s the “What” that will be built.
• It contains rough estimates of both business value
and development effort.
• Product Owner is in charge of defining priorities in
the Product Backlog.
• Maintains Story Lists.
Product Backlog

Product Backlog (cont’d)

101
As a (role) I want
(something) so
that (benefit).
User Story

102
Card
User Story information is lightweight. It fits onto a single index card.
Conversation
When the story is selected for a Sprint, further details are finalized in
conversations with the Product Owner.
Confirmation
Acceptance criteria are added to the User Story, to confirm the
feature was implemented properly.
User Story 3C Principles

103
As a customer service representative, I
can search for a customer so that I can
view his/her account details.
• When searching by a valid account
number, the account is shown.
• When searching by a valid name and
Citizenship ID, the account is shown.
• If no results are found, show
appropriate message.
• Acceptance tests?
Example of User Story

104
Every user story (requirement) should meet the below
criteria (INVEST acronym) for it to be considered
complete.
• Independent
• Negotiable
• Valuable (to users/customers)
• Estimate-able
• Small
• Testable
User Story INVEST Principle

Hierarchy of Requirements
As known
as Epic

106
Theme
▪ A set of related user stories that may be
combined together and treated as a single entity
for either estimating or release planning
▪ Kept for ease of estimation and planning
▪ Example: Support for Database → Will involve
defining schema, migrating existing data,
creating reports and so on
Epic
▪ Large user stories with low priority and too big to
implement on one iteration
▪ Broken down further into smaller user stories
and the lower level child stories are assigned
priorities for planning
Relationship Between Theme and Epic

• Epic describes what the customer would typically request and understand
• Epic typically contains one or more stories
• Agile team along with PO breaks epic into stories (independent and deliverable)
• Example
o Epic: As a credit analyst, I need the ability to check the customer’s credit
rating
o Story 1: As a credit analyst, I need the ability to check the prior payment
history of the customer
o Story 2: As a credit analyst, I need the ability to calculate our internal credit
rating based on history and credit report
Relationship Between Epic and Story

108
Jeff Patton:
• Decompose High Level Activity into
a workflow with further
decomposition
• Divide into a hierarchy of Epics,
Themes and Stories
• Natural prioritization can emerge
Story Mapping

User Story Splitting
110
• A story may not fit within an iteration, it’s too large to estimate (epic)
• Examples (from Mike Cohn – Agile Estimating and Planning)
In some cases a large story can be made much smaller by removing the handling of exceptional or error conditions from the
main story. For example, suppose you are working on a system to process loan repayments and have this user story: “As a
borrower, I want to payoff my loan.” When the team discusses this story, the product owner points out that if the borrower
inadvertently sends a check for more than the outstanding loan amount, a refund check has to be printed and mailed back to
the borrower. She then adds that this only applies for amounts over $2. This story could be split by writing the following
stories:
• Split by Data Boundary
• As a borrower, I want to pay off my loan
o As a borrower, I want to pay off my loan without overpayments
o As a borrower if I accidentally repay too much, I get a refund if it’s over $2
• Split by Operational Boundaries – C.R.U.D.
• Cross cutting concerns, e.g. logging can be another user story

111
Must have (or Minimum Usable Subset)
Should have
Could have
Won’t have (but Would like in future)
‘Must Haves‘ are features that must be included before the product can be launched. It is good to
have clarity on this before a project begins, as this is the minimum scope for the product to be useful.
‘Should Haves‘ are features that are not critical to launch, but are considered to be important and of
a high value to the user.
Requirements Prioritization: MoSCoW

Requirements Prioritization: MoSCoW (cont’d)
‘Could Haves‘ are features that are nice to have and could potentially
be included without incurring too much effort or cost. These will be the
first features to be removed from scope if the project’s timescales are
later at risk.
‘Won’t Haves‘ are features that have been requested but are explicitly
excluded from scope for the planned duration, and may be included in
a future phase of development.

113
Project Estimation and Planning
Module 6

114
• Expert Judgement
• Analogous/Top-Down
• Parametric Estimate
• Bottom Up
Decomposition
Mainstream Estimation Techniques

115
• An iterative approach to estimating
• Each estimator is given a deck of cards, each card has a
valid estimate (Fibonacci series) written on it
• Customer/Product owner reads a story and it’s discussed
briefly
• Each estimator selects a card that’s his or her estimate
• Cards are turned over so all can see them
• Discuss differences (especially outliers)
• Re-estimate until estimates converge
Estimation Through Playing Poker

116
PO Presents
Story
• Team asks
questions
Team Members
choose a card
• Discussion about
values occurs
Agreement? • Yes – value noted –
start with next story
No – Discuss differences
High and Low
How to Play the Poker

117
• The rate at which the team is delivering, measured in story points per
day/sprint
• Only user stories that meet the defined ‘Done’ criteria shall be accounted for
while counting story points
• Partially completed stories shall not be considered
❖ Don’t imply precision by saying you completed 4.7 points out of 8
❖ That last 10% can take 90% of the time
❖ The business value is not achieved until it is done completely in all respects
• The average velocity of the previous sprints is typically used as the planned
velocity of the next sprint.
Measuring Velocity

118
1 1 1
2 2
3
2
15 Story Points 12 Story Points 14 Story Points
Team velocity is ~14 Points per Sprint
5
1 1 1 1
2 2 2
1 1 1
2 2
1
1
3
2
Sprint 1 Sprint 2 Sprint 3
Determining Team Velocity

119
Consider
• Risk (sharp knife, spiky/slippery skin)
• Effort (size of fruit)
• Complexity (cutting difficulty)
• Relativity (to existing estimates)
Definition of Done
• All seeds removed (except strawberry &
banana)
• All fruit to be washed
• Bite-sized pieces
Acceptance Criteria
• Rock melon, banana, mango, coconut, pineapple
skin off
• Pear, apple skin on
??? ??? ??? ??? ???
1/2 point 5 points 8 points 20 points
Example of Estimation

120
Adapted from Ilan Goldstein
Back to Fruit Salad

5 Levels of Scrum Planning

122
• Release Plan is a high
level plan for multiple
sprints
• Contains features that will
be implemented during
this release and a broad
sprint by sprint plan.
• This will change when
navigating from Sprint to
Sprint.
Understand the goal
Understand the customer requirement
Prioritize and estimate the backlog
Calculate the team velocity
Create a release plan
Communicate the release plan
Release Planning

123
RELEASE 1.0
RELEASE 1.5
RELEASE 2.0
Where is Release Planning at?

Sprint
Planning

126
Calculate the team’s
capacity availability for
the upcoming Sprint
1
5 people x 2 wks x 6hrs/day: 300.0
Minus vacation: 224.0
Minus 20% Slack/ Risk Buffer: 179.2
Commitment Cap: 179.2
Prepare task estimates
for prioritized user stories
of upcoming sprint
2
Compare capacity vs
estimates and confirm
commitment is reasonable
3
176
Hrs
179 Hrs ≈ 176 Hrs
Sprint Planning (cont’d)

127
• In the first half, the Product Owner briefs the team on the next priorities from the Product
Backlog, and the Team selects a set of items they deem reasonable.
• In the second half, the team decomposes the commitments into the Sprint Backlog of
action items and tasks needed to accomplish those commitments.
• Many teams spend too much effort pre-assigning Sprint Backlog action items to Team
Members, often causing the Sprint Planning to last many hours too long.
• Consider leaving the task assignments until later. This will allow Team Members the
opportunity to self-assign the tasks, generating more buy-in.
• The Sprint Backlog is an imperfect living work plan. 30-40% of the Sprint Backlog tasks will
change over the course of the Sprint.
• Consider deferring the task definition for those items that are not fully understood.
Divide the Planning
into 2 Halves
Defer Task
Assignments
Defer Unknown
Details
Sprint Planning – Best Practice

Scrum Planning with MS Project

129
Project Execution
Module 7

Stages of Expertise
131Source: Meilir Page-Jones
2018 Agile with Scrum

Stages of Expertise (cont’d)
132Source: Meilir Page-Jones2018 Agile with Scrum

Stages of Expertise (cont’d)
133Source: Meilir Page-Jones2018 Agile with Scrum

134
Project Monitoring and Tracking
Module 8

135
Purpose
• Enable to team to share progress with each other
• Make visible blocks (impediments) daily for whole team to
see
Everyone reports 3 things
• What did I do since the last Daily Scrum Meeting?
• What will I try to do by the next Daily Scrum meeting?
• What are the challenges/blockers, I need help on
Duration: Approx 3 minutes per person
Participants: Team and Scrum Master only. PO can be part of
the meeting.
Daily Standup

136
• Was first introduced as part of Toyota Production System in early 1980s
• Was coined by Alistair Cockburn in 2001
• Graphical Representation of Project Status & Key aspects displayed in Team Workspace
• Can be handwritten, drawn, printed
• Keeps team focused on tasks and actions needing priority and attention
• Helps drive transparency across the organization
• Task Boards, Graphical Representations, Burn-down Charts are examples of Information
Radiators.
• Should be designed in a way that enables readability and usability
• Should be included as part of the agile process practiced for effective results

Information Radiators: Task Board

October 2018
Agile with Scrum
138

Information Radiators: Task Board (cont’d)

141
• Burndown chart is a plot of work remaining on the vertical axis and time on the
horizontal axis.
• Each point on the chart shows how much work is left to do at the end of that day.
• Simple concept to see that the work remaining must reach zero by a defined date.
• Trends indicate whether the team is working per plan or ahead or behind schedule
and enables team to take timely action.
Burn Down Chart

Burn Down Chart (cont’d)

143
• Tracks progress towards project completion
• Shows work to be delivered and completed work
• Measure of work can be task hours / story points
• Tracks when work has been added or removed
• Tracks where work is being removed to meet fixed deadline
• Distance between the two lines is the amount of work remaining
Burnup Chart

Burnup Chart (cont’d)

145
• Purpose is to demonstrate the product/work done in the sprint to PO and
stakeholders and take feedback
• Meeting typically conducted at the end of each Sprint and lasts between 1 to 2 hours
• Formal meeting but conducted informally
• Only completed items that meet Done criteria should be demonstrated
• After the meeting, PO reviews sprint commitments, what has been completed that
meets DONE criteria
• Incomplete items if any are added back to Product Backlog
• Feature changes, scope changes are updated to the Product Backlog
Sprint Review

146
• Purpose is to discuss the good and bad experiences during the just concluded sprint, identify
improvement items and owners
• Enables the team to resolve problems faster and become more productive, efficient and self-
managed
• Meeting facilitated by Scrum Master and lasts 1 to 2 hours
• PO also attends this meeting
• Typically, discussion is focused on below three aspects
❖ What went well during the sprint cycle?
❖ What went wrong during the sprint cycle?
❖ What could we do differently to improve?
❖ Scrum Master takes lead in prioritizing action items and ensuring its implementation
Sprint Retrospective

147
Scrum Adoption
Module 9

Reasons of
Adoption

Industries That Adopt Agile/Scrum

Benefits of
Adoption
Agile with Scrum October 2018 150

Successful
Criteria for
Scrum

Successful
Criteria for
Agile

153
Key Challenges
Module 10

154
How difficult were the following issues to
address during your Agile/Scrum Adoption?
How important were the following issues to
address during your Agile/Scrum Adoption?
Key Challenges

Key
Challenges
(cont’d)

156
Key Success Factors
Module 11

October 2018 ScrumAlliance: State of Scrum Report 157

Having Adoption Roadmap
Readiness
Check
Education
Pilot
Implementation
Reflect, Inspect
& Adapt
Scale
Enterprise
Wide

Do Rollout Your First Scrum Pilot Project

160
Kanban and TDD Framework
Module 12

Agile Frameworks
• Extreme Programming (XP)
Type of software development intended to improve quality and
responsiveness to evolving customer requirements. The
principles includes feedback, assuming simplicity, and
embracing change.
• Feature-Driven Development (FDD)
This iterative and incremental software development process
blends industry best practices into one approach. There are five
basic activities: develop overall model, build feature list, plan by
feature, design by feature, and build by feature.

Agile Frameworks (cont’d)
• Adaptive System Development (ASD)
The idea that projects should always be in a state of continuous
adaptation. It has a cycle of three repeating series: speculate,
collaborate, and learn.
• Dynamic Systems Development Method (DSDM)
Is used for developing software and non-IT solutions. It addresses the
common failures of IT projects, like going over budget, missing
deadlines, and lack of user involvement.
The eight principles: focus on the business need, deliver on time,
collaborate, never compromise quality, build incrementally from firm
foundations, develop iteratively, communicate continuously and clearly,
and demonstrate control.

• Lean Software Development (LSD)
Takes Lean manufacturing and Lean IT principles and applies them to
software development. It can be characterized by seven principles:
eliminate waste, amplify learning, decide as late as possible, deliver as
fast as possible, empower the team, build integrity in, and see the
whole.
• Kanban
Meaning “visual sign” or “card” in Japanese
It promotes small, continuous changes to your current system. Its
principles include: visualize the workflow, limit work in progress,
manage and enhance the flow, make policies explicit, and
continuously improve.

• Test-Driven Development (TDD)
It relies on repetitive, short development cycles. First, a developer
writes an (initially failing) automated test case for a new feature
and quickly adds a test with the minimum amount of code to pass
that test. Then, he/she refactors the new code to acceptable
standards.
• Scaled Agile Framework (SAFe)
A very structured method to help large businesses get started with
adopting Agile. Based on Lean and Agile principles and tackles tough
issues in big organizations, like architecture, integration, funding, and
roles at scale. It has three levels: team, program, and portfolio.

• Rapid Application Development (RAD)
Its’ approach to software development puts more emphasis
on development than planning tasks.
It follows an incremental model, where each component is
developed in parallel. The phases in RAD are: business
modelling, data modelling, process modelling, application
generation, and testing and turnover.

Scrum vs Kanban

Test-Driven Development

172
Scrum Documentation
Module 13

What to
Document?
Product Backlog
Sprint Planning
Sprint Backlog
Sprint Review
Sprint Restrospective
Burn-Up Chart
Burn-Down Chart
Release Planning
Release Backlog

174
Scrum Tools and Software
Module 14

Recommended
• OpenProject (Open Source; Agile, Scrum, Waterfall)
• OrangeScrum (Open Source; Agile, Scrum, Kanban)
• Taiga (Open Source; Agile, Scrum, Kanban)
• JIRA (Agile, Scrum, Kanban)
• Trello
• Slack

176
Final Q & A
Agile with Scrum

Thank You!
Image: HappyJump

Leveraging Agile Project Management with Scrum

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Leveraging Agile Project Management with Scrum

Similaire à Leveraging Agile Project Management with Scrum (20)

Plus de Goutama Bachtiar

Plus de Goutama Bachtiar (20)

Dernier

Dernier (15)

Leveraging Agile Project Management with Scrum