1.
[Project Name] Kick Off
PREPARED BY:
DATE:

2.
Agenda
1. Introductions
2.Agile Project Charter
3. RACI Matrix
4. Methodology
5. Communications plan
6. Change and Scope Mgmt
7. Risk Mgmt
8. Quality Mgmt
9. High level Agile Project Plan
10. Sample Weekly Status Report
11. Project Documentation Repository

3.
Project Vision Business Value
High Level Scope Key Milestones
Success Metrics Key Stakeholders
Sponsor:
Client SMEs:
Project Manager:
Lead Business Analyst:
Technical Lead:
Test Manager:
[Project Name] Agile Project Charter

4.
RACI Matrix

5.
Methodology – Why Agile?

6.
Methodology - Overview
Client Client

7.
[Project Name] Communication Plan
Communication
Goal
Communication
Tool
Audience Input Output Frequency
Product Backlog
Refinement
(PBR)
In-person
meeting
Client
Project Manager
Business Analyst
Technical Lead
Developers
Test Manager
Current Backlog
Refined backlog -
new items added review,
change of priorities review
Monthly
Sprint Planning
In-person
meeting
Technical Lead
Business Analyst
Developers
Test Manager
Refined and
prioritized backlog
Sprint Backlog
Monthly, after
PBR
Sprint Goal and
Sprint Scope
Email
Client
Project Manager
Business Analyst
Technical Lead
Developers
Test Manager
Sprint Backlog
Keeping the
group informed
Monthly,
after Sprint
Planning
Standup
In-person
meeting
Technical Lead
Developers
Test Manager
Discussion on
work completed,
work to be completed
and impediments
Knowledge and
escalation of
impediments
Daily
Weekly
Status Report
In-person
meeting
Client
Project Manager
Business Analyst
Technical Lead
Test Manager
Status report slide
Alignment and
knwoledge of status
Weekly
Sprint Review
and
Pre-Sprint
Planning
In-person
meeting
Client
Project Manager
Business Analyst
Technical Lead
Test Manager
Finished work product,
Refined Backlog
Acceptance of the work,
Priorities for next Sprint
Monthly

8.
Example Calendar

9.
Change and Scope Management - 1
Scope creep vs Value discovery
The 80/20 rule: 80% of the value comes from 20% of the functionality. Implement those 20% first.

10.
Change and Scope Management - 2
Scope Management with Waterfall​ Scope Management with Agile​
Project teams attempt to identify and document complete
scope at the beginning of the project, when the teams are the
least informed about the product.​
Project teams gather high-level requirements at the beginning of the project, breaking down and
further detailing requirements that are going to be implemented in the immediate future.
Requirements are gathered and refined throughout the project as the team’s knowledge of
customer needs and project realities grows.​
Organizations view scope change after the requirements
phase is complete as negative.​
Organizations view change as a positive way to improve a product as the project progresses.
Project managers control and discourage changes after
stakeholders sign off on requirements.​
Change management is an inherent part of agile processes. You assess scope and have an
opportunity to include new requirements with every sprint.​
The customer determines the value and priority of new requirements and adds those requirements
to the product backlog.​
The cost of change increases over time, while the ability to
make changes decreases.​
You fix resources and schedule initially. New features with high priority don’t necessarily cause
budget or schedule slip; they simply push out the lowest-priority features.​
Iterative development allows for changes with each new sprint.​
Projects often include scope bloat, unnecessary product
features included out of fear of mid-project change.​
The project team determines scope by considering which features directly support the product
vision, the release goal, and the sprint goal. The development team creates the most valuable
features first to guarantee their inclusion and to ship those features as soon as possible.​
Less valuable features might never be created, which may be acceptable to the business and the
customer after they have the highest-value features.​

11.
Change and Scope Management - 3
1. If the change request will take less than
2 hours to implement (e.g change label
in the UI), it will be accommodated
immediately in the current sprint
2. If the change request requires more
than 2 hours of development work, the
following process needs to be followed.
1
• The client iniforms the Product Owner about the change request
2
• The change request is reviewed at PBR meeting
3
• The change request is further refined and broken down, if required
4
• The change request is prioritized by the client, relative to the rest of
the backlog
5
• If it is prioritized for inclusion into next sprint, it will be developed
then
6
• If not prioritized for next sprint, it stays on the backlog for future
prioritization

12.
Risk Management
1. Identify – risks are identified on an ongoing basis, through formal risk identification workshops
as well as during day-to-day activities.
2. Assess – once identified a risk is assessed to establish the likelihood of it occurring and the
impact it will have if it occurs.
Risk Assessment Matrix
3. Respond – there are several actions to respond to a risk following the ROAM model – resolve,
assign an owner, accept or mitigate.
4. Monitor – progress of the risk responses needs to be monitored and controlled, with corrective
action taken if needed. Typically, progress is assessed via project team meetings.
Who can identify risks? Any stakeholder
How is risk expressed? A risk can be expressed either on a team meeting or via contacting the project manager
How do we track the risks? Global risk register maintained by the project manager and risk section in weekly status report for shorter
timescale

13.
Quality Management
1. Define Project Quality
2. Measure Project Quality
3. Quality Assurance
4. Quality Control

14.
High-level Agile Project Plan

15.
Project Title
Project Vision
Key Contact
Progress this Period:
 Bullet 1
 Bullet 2
Planned Activity:
 Bullet 1
 Bullet 2
Key Risks/Issues: Key Milestones (Upcoming/Recently Completed):
Schedule Scope Budget Benefit Resources
Sample Weekly Status Report Last Updated
Date:
Risk /Issue RAG ROAM Comment
Risk 1 R
Risk 2 O Owner John
Milestone RAG % Target Date
Milestone 1 100 3/3/2021
Milestone 2 10 31/3/2021

16.
Project Documentation Repository
 Describe Repository (SharePoint, MS Teams, Smartsheets, etc)
 Provide links where applicable

17.
QUESTIONS?