WHO PM Framework using Agile

Product backlog
ID Card Charter
Product backlog
status

Retrospective

Sprint review Close

Pro
jec
Are you ready for Agile? Use simple Agile raediness cheklist. t
Da
Bef
sh
ore
bo
Aft
ard
er
Project Request / ID Card
The Project Request / ID Card is used for identifying projects, before an investment decision has been made. The project request ensures the investment is a good fit in terms of strategy, budget, and
portfolio.

Overview

*Project name: *Project sponsor/Product Owner:

If the Project is part of a larger Agile Project Manager (if known):
Programme/Resolution, provide the
Programme/Resolution Name:
*Major Office / Sponsoring Cluster / Proposed tier: Please Select
Technical Unit or Function:
PB category and area: Please Select Project type: Please Select
*Project requestor: Project priority:
*Project request date: *Prepared by:

The high level objective which the project/programme is intended to achieve.

Project goal:

Project Definition

*Business opportunity or problem: describe the specific opportunity or problem the project is going to address (max 50-200 words).

*Recommended solution: provide a brief overview of how this project will solve the opportunity/problem identified above, what areas it will cover within the scope, and who is target audience of the
project outcome , if applicable. Use clear terms, avoid acronyms, and keep this project description brief and concise. The Project Charter will provide additional detail.

Primary project benefit and purpose: what is the primary intended purpose of this Please Select
project?

Primary project outcome: Please Select

How does Outcome helps achieve WHO PB Programme Area Output?

*Estimated total cost: What is the estimated cost for the project, including activity and staff?

*Estimated resource requirements: anticipated number of FTE (Full Time Equivalent) WHO staff and contingent/external resource(s).
WHO staff FTE: Contingent resource(s)

*Estimated project schedule: anticipated planned start & finish dates for the project in MM/DD/YYYY format.
*Planned start: *Planned finish:

Region impacted: what region or country is impacted by the project?

AFR PAH SEAR EUR EMR WPR HQ

Countries impacted:
(if not the whole region)

Expected organizational change impact: Please Select

Strategic priorities and goals: Please Select

UN’s Sustainable Development Goals (SDG's): Please Select
Project Charter
The Project Charter, when approved, authorizes the project. The Project scope, timelines, resources, and cost commitments must be approved before the project may advance.

Overview

*Project name: 0 *Project sponsor/Product Owner: 0

If the Project is part of a larger 0 *Agile Project Manager: 0
Programme/Resolution, provide the
Programme/Resolution Name:
*Major Office / Sponsoring Cluster / 0 *Project tier: Please Select
Technical Unit or Function:
PB category and area: Please Select Project type: Please Select
*Project requestor: 0 *Project request date: 30/12/1899
Impact on GER Please Select *Charter prepared by:
Project code: Date (last revision):
Unique ID number generated by the system

The high level objective which the project/programme is intended to achieve. If you are applying agile approach this is your project vision.
Project Goal: 0

Project Details

*Business opportunity or problem: Describe the specific opportunity or problem the project is going to address.
0

Additional Notes/Details regarding the opportunity (any changes in or developments to conditions, assumptions, or variables related to the solution that have arisen since the Project Request Card
was created and approved).

*Recommended solution: (as outlined in the Project Request / ID Card)

0

What is the proposed/recommended solution the project should implement? Additional Notes/Details regarding the opportunity/problem (any changes in or developments to conditions,
assumptions, or variables related to the opportunity/problem that have arisen since the Project Request Card was created and approved).

Out of scope: It is equally important to define what elements are out of scope in order to set stakeholder expectations accordingly. Just as with Requirements, through socialization and definition of the
project, you will discover more items to add to this list. Return back to further define out of scope items.

Out of scope item/feature Notes

<Add additional rows as necessary>
Project justification / business case:
Describe why an organization needs to implement a particular solution to a problem, and confirm the need for launching a project that addresses the problem through implementing the solution.

Implications of not completing this project:

What happens if we don't do this project? What is the risk of doing nothing?

* Epics (key deliverables)

List the key project deliverables in the following table. For each deliverable, provide a deliverable # in the form of D000, a title for the deliverable, the lead responsible for completing the deliverable, the
format for the deliverable, and a short description (including timeline for the deliverable).
Key project deliverable #: Title: Leading Unit: Format:
E001
Short description:

E002
Short description:

E003
Short description:

Key assumptions: as you developed your list of requirements and out of scope items, you made certain assumptions. Note any assumptions that might impact the overall success of your project,
including assumptions that might be dependencies on other teams, acquiring resources, completing work on time and/or other.

Key assumptions, constraints & dependencies Notes

<Add additional rows as necessary>

Core Project Team

Project team: define the individuals on the project team, their roles, originating departments, and estimated time commitments for the duration of the project. This list will develop as you work through
your project. Refer back to this list and make changes as your project progresses.
Name Role (on the project) Department Time commitment (%)

<Add additional rows as necessary>

*Project Cost

Cost Estimated cost Planned timeline to incur the cost (Q/FY) Comment
Total project cost

Agile project manager signature: Date: Product Owner signature: Date:

Project Epics
An epic is a large body of work that can be broken down into a number of smaller stories.
The key project deliverables defined within Project Charter, and approved by project board, can be a good base for a building Project Epics.

Epic #
Overview

*Project Name: *Product Owner:

Assigned Group/Team: *Agile Project Manager:
Prepared by: Date (last revision):

Title:

Description

Epic #
Overview

*Product: *Product Owner:

Assigned Group/Team: *Agile Project Manager:
Prepared by: Date (last revision):

Title:

Description
Agile User Stories - Product Backlog
The Product Backlog is an ordered list of items (e.g. User Stories). The items in the Product Backlog include features that deliver the Product Vision. The highest prioritized items need to be better detailed and specified – the team needs to able to estimate and test those items.
User Stories are short descriptions of a smaller piece of deliverables/epics/business requrement, written in the user’s language. Agile Teams implement smaller pieces of complete solution/product and those are sized so they can be completed in a single Iteration.

Definition of Done Estimation Points (value in

User Story ID User Story Title Description Priority State
(Acceptance Criteria) points, days, hours)

STR# Please Select Please Select

STR# Please Select Please Select

STR# Please Select Please Select

Please Select Please Select

Please Select Please Select

Please Select Please Select

Please Select Please Select

Please Select Please Select

Please Select Please Select

Please Select Please Select

Sprint Backlog
The Sprint Backlog is a list of items which are committed to be accomplished during the sprint. The items for the Sprint Backlog are taken out from the Product Backlog. Items not completed in the sprint are not moved to the next sprint, but are returned in the Product Backlog instead, or marked as unassigned to the Sprint till next Sprint planning meeting.

The Product Backlog is an ordered list of items (e.g. User Stories). The items in the Product Backlog include features that deliver the Product Vision. The highest prioritized items need to be better detailed and specified – the team needs to able to estimate and test those items.

Assigned To
Task ID Task Name Sprint Start Date Finish Date Assignment group Priority State Estimation Points Story ID
Sprint

SPRINT #

TSK# Please Select Please Select Select

TSK# Please Select Please Select Select

TSK# Please Select Please Select Select

TSK# Please Select Please Select Select

TSK# Please Select Please Select Select

SPRINT #

TSK# Please Select Please Select Select

TSK# Please Select Please Select Select

TSK# Please Select Please Select Select

TSK# Please Select Please Select Select

TSK# Please Select Please Select Select

SPRINT #

TSK# Please Select Please Select Select

TSK# Please Select Please Select Select

TSK# Please Select Please Select Select

TSK# Please Select Please Select Select

TSK# Please Select Please Select Select

 Gantt Chart_x000D_

DURATION
AT RISK AGILE PHASE FEATURE TYPE RESPONSIBLE ESTIMATION POINTS START FINISH STATUS COMMENTS
(DAYS)

Sprint 1

User Story/Task

User Story/Task

User Story/Task

Sprint 2

User Story/Task

User Story/Task

User Story/Task

Sprint 3

User Story/Task

User Story/Task

User Story/Task

12/30/99 1/1/00 1/3/00 1/5/00 1/7/00 1/9/00 1/11/00

Sprint 1

User Story/Task

User Story/Task

User Story/Task

Sprint 2

User Story/Task

User Story/Task

User Story/Task

Sprint 3

User Story/Task

User Story/Task

User Story/Task
 STORY ORIGINAL SPRINT
BACKLOG TASK & ID ASSIGNED TO STATUS DAY 1 DAY 2 DAY 3 DAY 4 DAY 5
POINTS ESTIMATE REVIEW
SPRINT BURNDOWN
User Story #1

1
Task

Task

Task 0.9

Task

User Story #2
0.8
Task

Task

Task 0.7

Task

User Story #3
0.6
Task

Task
0.5
Task

Task

User Story #4 0.4

Task

Task
0.3
Task

Task

User Story #5 0.2

Task

Task
0.1

Task

Task
0
TOTAL 0 0 0 0 0 0 0 DAY 1 DAY 2 DAY 3 DAY 4 DAY 5 SPRINT REVIEW
Sprint Review
Ggoal of the Sprint Review is to show a results of the Sprint as working solution, share the knowladge, check the backlog items, create new backlog items if needed. Participants of the review meeting are Product
Owner, Agile project manager, Team members, and optional any stakeholders relevant for sprint content.

Practical note: Time box the meeting for maximum 2h, prepare agenda and presentation. It is imporatnt to remind participants on the sprint goal before start showing sprint results. Modearte meeting in simple steps:
- Product owner or Agile project manager opens the meeting and remembers the team of the sprint goal
- Team presents the finalized backlog items (if possible on a real system – no PowerPoint, screenshots etc.)
- Product owner and end users are allowed to test the functionality on their own
- Create new backlog items if:
changes are required for a feature
new ideas come up
errors are identified

*Project/Programme Name:
*Sprint #:

Overall goal of the sprint

Describe overall goal of the sprint.

Sprint acceptance criteria

Describe the criterai the product owner uses to confirm the story has been implemented to his or her satisfaction.

Sprint acceptance decision

Product owner and stakeholders accept the results of the sprint or sprint items need to be returend in the product backlog. Describe final decision and note comments if any.

New backlog items / Notes

List any new backlog items if needed after the sprint review.
Sprint Retrospective
The Sprint Retrospective is used to capture the experience gained during a sprint asking the team direct questions about the sprint: what was good and what was bad, then capturing ideas and actions from the team
that could be taken into next sprint.

Practical note: Instead of this template you can use a whiteboard or flipchart, and sticky notes to vizualize retrospective with your team. Gather team and show them whiteboard/flipchar divided in 4 boxes: What went
well?, What didn't go well?, Ideas, and Actions. Ask the participants to list their thoughts on sticky notes and place them in the appropriate box.Get everything recorded on the board where it’s up for everyone to see.
Reflect all inputs on the board, discuss them with the team and come up with actions that they are going to takefor next sprints.

*Project/Programme Name:
*Sprint #:

What went well?

What aspects of the project went particulary well? Why?

What didn't go well?

What could have been better / didn't go well? Why?

What would we do differently next time? Ideas for improvement?

If you had to do the same work over again, what would you do differently? What advice would you give to a project team doing the same or similar work?

Actions
An action plan with clear accountability to ensure that lessons are not lost.
User Acceptance Testing (UAT) Sign-Off
The UAT Sign-Off form is used to formally approve and accept testing results of delivered Solution. UAT Sign-Off is signed-off by Project Sponsor and Business Requestor.

*Project name: 0
*Product owner: 0

*Agile Project Manager: 0

*Test type: Please Select

Testing start date: Testing finish date: Test lead:

Test Scope
List of elements subjected to the tests.
Test results
Tested key features and functionalities Comment
confirmed
Please Select
Please Select
Please Select
Please Select
Please Select
Please Select
Please Select
Please Select
Please Select
Please Select

Test Summary
Summary of the testing results. Please refer to the detail test results in the Testing Tool.

Test results summary Total number of test cases Percent of test cases Defect priority (for failed test cases)

Total test cases passed

Total test cases failed
Total test cases remaining open

Summary and acceptance of the testing results. Please check the statement matching the results of the testing review.
Above listed application(s)/solution(s) has been reviewed:

The test(s) is (are) signed-off and accepted.

The test(s) is (are) signed-off and accepted with subject to inclusion of the comments noted below.

The test(s) is (are) not signed-off accepted for the reasons noted below.

Comments
Please note any comments regards to the testing results to be taken into account as conditional acceptance of the delivered solution.

Signatories
This document has been reviewed and approved by the relevant stakeholders in the project.

Prepared by:
<Name> <Title> <Date> <Approval signature> Tester/Test manager

Signed by:
<Name> <Title> <Date> <Approval signature> Project sponsor/Business requestor

Signed by:
<Name> <Title> <Date> <Approval signature> Project manager
Project Closure
To be completed by Project Manager and the Project Team at the Project Closing.

*Project name: 0
*Product owner: 0

*Agile Project Manager: 0

0
Project overview:

Schedule Cost
Planned/Baseline start date Planned/Baseline finish date Planned/Baseline project cost
30/12/1899 30/12/1899 $0.00
Actual start date Actual finish date Actual project cost

Key Project Deliverables Acceptance

Each major project deliverable needs to be approved, and by listing those deliverables separately we help to ensure that none are missed. Please list deliverables accepted and approved by project
stakeholders.
Key project requirements/deliverables Accepted by Acceptance date Comment
D001
D002
D003
<Add additional rows as necessary>

Benefits Realization
Describe benefits realized by the project and an explanation for the variance (if any).

Contract Closure
If vendors/contractors are involved, there needs to be confirmation that all of the accountabilities have been completed from both sides of the relationship.
Payments
Vendor/Contractor name Contract reference Work complete?
complete?
Please Select Please Select
Please Select Please Select
Please Select Please Select
<Add additional rows as necessary>

Administrative Closure
One of the final tasks for the project manager is to complete all of the administrative tasks that constitute closing down the project. This section is a simple checklist for the project manager to complete as each
of the items is completed.

Item Completed
Project team
Performance reports shared with functional manager Please Select
One-on-one debriefs completed (where appropriate) Please Select
Coaching plans updated (where appropriate) Please Select
Resources released to functional groups Please Select
Project closing recognition/celebration completed Please Select
Project documents
All acceptances received Please Select
Lessons learned consolidation done Please Select
Contract closure completed Please Select
Final project report completed (this document) Please Select
All project documents archived Please Select
Project manager
Wrap up meeting with sponsor, customer, etc. completed Please Select
Personal development plan updated (when appropriate) Please Select
<Add additional rows as necessary>

Signatories
This document has been reviewed and approved by the relevant stakeholders in the project.
Name, Title, Date, Approval Signature
<Name> <Title> <Date> <Approval signature> Project requestor

<Name> <Title> <Date> <Approval signature> Project sponsor

<Name> <Title> <Date> <Approval signature> Senior stakeholder (if different than sponsor)
Agile References

Agile project roles

Primary Project Sponsor In the organizational context, we still will have this role within the projects. In WHO usually sponsor in usually senior management level, director or
above. A project sponsor is typically responsible for initiating, ensuring, approving, and establishing a series of key aspects in relation to the project, which can be summed up
under categories of vision, governance, and value/benefits realization. Applying the Agile discipline he/she will nominate the Product Owner.

Product Owner Expected to do the communication with all stakeholders, maintain the Product Backlog, and ensure that everyone knows the priorities. Key activities and
responsibilities of product owner are:
- owns the Product Backlog as he/she needs to maximize the ROI of the Product/Solution
- responsible to define the content and prioritize the value
- decides Release date and content
- discusses and agrees with the Stakeholders what to do, and why
- discusses and agrees with the Development Team how to represent in the backlog what needs to be done
- accepts or Rejects the results of a Sprint

Process Master (e.g. Scrum)/Agile Project Manager Helps the Scrum Team perform at their highest level. He/her also protect the team from both internal and external
distractions, removing bottlenecks, communicate with project stakeholders and product owner. Some typical responsibilities are: - responsible for applying Agile discipline and
coaches every participant in the correct usage of the agile process, ceremonies, artefacts, as well as role responsibilities.
- helps the Product Owner in preparing the product backlog and preparing sprint planning meetings with the team
- helps the Development Team in preparing the sprint review meeting
- prepares and facilitates the daily stand-up meetings
- protects the Development Team from interferences during a sprint, and coaches team to become more effective
- update the burndown chart, agile task board or any other used technique to visualize progress
- communicate actively with project stakeholders, project board

Agile Team Structured and empowered to organize and manage their own work. The resulting synergy optimizes overall efficiency and effectiveness.
Is a cross-functional team, meaning every skill needed to create a potentially shippable product increment must be in the team. For the typical Scrum team it is usually sized
7+-2 members. Key team responsibilities are:
- responsible for the Product Quality
- defines how to implement the functionalities into the Product/Solution
- prepares the Sprint Review Meeting and performs the Sprint Retrospectives to improve efficiency

Other involved stakeholders: Client; Business Owners; Technical Owners

Information

Epic & User Stories

Epics are large user stories that can be broken down into a number of smaller user stories. Epics define the services that the system must provide to solve the customer's
problem. 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 pattern: As a <type of user>, I want to <some goal> so I can <some reason> .

Click here to go back to the Epics

Click here to go back to the User Stories

WHO Project Categorization – Tier Definition Guidelines

Click here to go back to the Project Request / ID Card

Project Type
1 Accreditation, certification - Institutions, Courses, Process, Achievement (e.g. elimination)
2 Assessment, review, analysis - Situation analysis, Evaluation, Risk assessment, Programme review, Health systems review, Policy analysis/ monitoring
3 Best practice - Identification/ consolidation, Dissemination/ sharing, Support for adoption,
4 Guidance /Guidelines - Clinical guidelines, Programmatic guidelines, System development/ operation, Maintenance
5 Norms and standards - Development, Support for implementation, Standard operating procedures
6 Institution- building - Center of excellence, Networks (e.g. lab network), Collaborating centers
7 Research/Operational Research - Prioritization/ agenda, Design/ proposal/ funding, Conduct/implementation, Findings/dissemination/peer reviewed journal publications, New/innovativ
8 Prequalification - Process/ mechanism, Development support, Consultation
9 Policy - WHO internal policies, Support to development/ dialogue /forum, Guidance/advice, Evidence base for policies/effectiveness review
10 Resolutions, declarations - Programme-related, Governance-related
11 Strategies and plans - Development of strategies/ strategic framework, Action plans/ implementation plans, Country Cooperation Strategies
12 Communications - Public advice; press releases, Communication materials, Publications, Media campaigns
13 Direct implementation - Mass drug administration, SIAs, Outreach
14 Initiatives and innovation - Pilots/ demonstration projects design, Implementation / promotion/diffusion
15 Profiles - Health systems, Country health development, Diseases /programmes, Sectors
16 Strategic information - Data management/ database, Monitoring systems, Observatories operations/ studies, Surveillance system design/ advice, Survey design/ conduct of survey, D
17 Stockpile - Emergency supply, Management system, Deployment
18 Advocacy - High-level commitment, Mobilization of support
19 Brokering - Multi-donor initiatives, Multi-sectoral initiatives, Alliances
20 Capacity building - Training, courses, workshops, Fellowship, In-country coaching, Study visits
21 Convening - Conferences, public forum, Consultative meetings/Stakeholders meetings, Expert consultation, Governing body, Donor/partnership forum
22 Country support - Direct support to country activity, Proposal development, Expert advice
23 Governance - Development of mechanism, Support through Secretariat role, Oversight role
24 Emergency/crisis- related - Early warning systems, Response, Risk management, Health cluster coordination
25 Networks, partnerships, linkages - Mechanism (establishment), Mobilization, Engagement with Global Health Initiatives
26 Procurement - Drugs, Goods and/or commodities, Vaccines
Click here to go back to the Project Request/ID Card

Project Priority Definition Guideline

Please refer to the questions below as a guideline to give priority to the projects/programme, and assist executives in choosing the most appropriate projects, with defining
proposed priority of project/programme requested. The high priority would positively answer the alignment questions.
Is it part of the Org's priority?
The proposal, to be worth considering, should be aligned with the Organization's General Programme of Work, RD or DDG or ADG priorities, or is in the programme budget
outcomes and outputs.
Is it in the Risk Register?
This is to consider that the worthiness of the proposal is relatively higher if indeed it is an identified corporate critical or severe risk (in the Risk Management Tool managed by
CRE). To be cross-checked with CRE if needed.
Is it part of Transformation?
Is there evidence (documents, links to documents, sites, etc.) that will demonstrate that the proposal is linked to the Transformation initiative
Is it driven by regulation, mandate, compliance (audit), technological obsolescence?
Is there evidence (attached documents, links to documents, sites, etc.) that will demonstrate that the proposal is a regulatory requirement (e.g. UN rules, ICSC, etc.), a WHA
or EB resolution, a recommendation by External or Internal Audit, and if there is an obsolescence that need to be addressed?
Click here to go back to the Project Request/ID Card

Organizational Change Impact assessment

The Organizational Change Impact is caused by the result of the project, which is not one of dimension in the Tier definition. For example, the Tier 1 projects may have a high
strategic impact, but may only cause or require a small change throughout the organization. A Tier 2 project might not have as high a strategic impact or be as costly as a
Tier 1 project, but it could require training of all staff to be implemented that would have a high organizational change impact. The distinction is separating the project strategic
impact, cost, size, etc. (i.e. the Tier), from the organizational change impact that will be caused by the project. For example, it could be Tier 1 that is a legal or regulatory
compliance project that has a high organizational change impact, or a Tier 1 that has very little organizational change impact. The Change Impact also determines the level of
the Change Management Plan the project should have in place.

Click here to go back to the Project Request/ID Card