ANYTHING BUT AGILE
Agile Project Plan Template
Authored by: Christophe Le Coent
From envisioning to close out
1. Contents
2.
Project Chartering............................................................................................ 2
Lift off planning................................................................................................... 2
Purpose............................................................................................................... 2
Alignment........................................................................................................... 2
Context............................................................................................................... 3
3.
Overall direction.............................................................................................. 3
Timeline summary.............................................................................................. 3
4.
Milestones and milestone management..........................................................3
Project Milestones............................................................................................... 3
Milestone tracking.............................................................................................. 5
Example.............................................................................................................. 6
5.
Risk and Issue management........................................................................... 6
Example.............................................................................................................. 6
6.
Assumption management............................................................................... 7
7.
Dependency management.............................................................................. 7
8.
Communication plan....................................................................................... 8
Minutes of meetings........................................................................................... 8
9.
Quality Plan..................................................................................................... 8
User Stories........................................................................................................ 8
Definition of Done (DoD).................................................................................... 9
Creation of the DoD......................................................................................... 9
Review of the DoD........................................................................................... 9
Example.......................................................................................................... 9
Design................................................................................................................ 9
10.
Test Strategy.............................................................................................. 10
The 4 quadrants............................................................................................... 10
The pyramid of tests......................................................................................... 10
11.
Software framework................................................................................... 11
12.
Release Management................................................................................. 11
13.
Defect Management................................................................................... 11
14.
Roles and Responsibilities..........................................................................11
15.
Resource Management and Planning.........................................................13
16.
Budget........................................................................................................ 13
People............................................................................................................... 13
Software........................................................................................................... 13
Hardware.......................................................................................................... 13
Trainings........................................................................................................... 14
Travels.............................................................................................................. 14
Miscellaneous................................................................................................... 14
Summary.......................................................................................................... 14
17.
KPIs (Project).............................................................................................. 14
Team Maturity................................................................................................... 14
Metrics.............................................................................................................. 14
18.
Compliance constraints.............................................................................. 14
19.
Reference................................................................................................... 14
Note from author: an agile project plan is a high level view on how the project
will be managed and it should never contrevine the Agile Manifesto and
principles. This document should remain lightweight and only use as guidelines
to drive the project to deliver valuable working software in short iterations to the
customers.
2. Project Chartering
Lift off planning
This documents value is in the lift off session [5] where stakeholders, team
members, product owners, scrum masters and project managers will create or
consolidate the project chartering: purpose of the project, alignment of the team
around the project and context of the project.
Initially, the Product Owner should draft the purpose of the product and the
context. Project chartering will be an output of the lift off session.
Purpose
What is the vision? Value to Attain
What is the mission? Result to Accomplish
What are the mission tests? Criteria for Success
Alignment
Values & Principles - Beliefs & Ideals about Work
Working Agreements - Operational Guidelines
Core Team - Cross-functional group with a common purpose
Context
Committed Resources - Organization Support
Boundaries & Interactions - Seeing the Systems
Prospective Analysis - Initial Projections
3. Overall direction
For the first user story implemented, we will deploy this feature to live. There is
only value if features are delivered to the customers.
Quality is not only for the code and test code, this is also about the quality of the
user stories, acceptance criteria, meetings, etc
To align the design of the solution with the user stories, we will use domain
driven design ideas and keep the design readable by the product owner of the
product.
Timeline summary
External
Releases:
Internal
milestone
s:
Re l a s e
S p e c u la
Envis on te Lift off Plan in Sprint 1 Sprint 2 Sprint 3 . sprint 6 . Sprint n Closure
g
1st release
2nd release
MVP
Final release
(Minimum Viable
Product)
TG3
TG1 TG2
TG3.
TG3.
TG4
TG5
Speculate & Adapt
Potentially Shippable Increments at the end of each
sprint as per DoD
4. Milestones and milestone management
Project Milestones
Milestones
Budget
approved
for
Gate
Definition
Phase
Resource is assigned for
Initiation phase to be
completed
Envision
Planne
d date
Type
Tracking
Speculatio
n phase
Initial
product
backlog
complete
Envision
phase
Complete*
T-shirt
sizing done
Budget
approved
for
completion
of the
project
High Level
Architectur
e agreed
Nonfunctional
requiremen
ts (KPIs)
defined
Test
Strategy
defined
Resource
plan
agreed
Speculate
phase
complete*
Lift Off
session
complete
Definition
TG1
TG2
Epics are defined
including architecture
and non-functional
requirements at high
level
Stakeholders approve
go-ahead to Initiation
phase
High level estimate is
done (x4 for
uncertainty) for
budgeting purpose of
the product backlog (at
epics level)
Budget is estimated and
agreed
Envision
Tracking
Envision
Go/No
Go
Speculat
e
Tracking
Speculat
e
Tracking
Including SW and HW
architecture, using DDD
[7]
Performance,
monitoring, load,
reliability, stability,
usability, Security, other
ilities
High level test strategy
Speculat
e
Tracking
Speculat
e
Tracking
Speculat
e
Tracking
Resource plan agreed
for the duration of the
project
Overall scope is defined
and estimated, Resource
available, team can start
detailing the plans
Team is aligned with a
clear purpose and
understand the context
of the project. Team has
defined their working
rules. Project
chartering is live
Quality standards are
Speculat
e
Tracking
Speculat
e
Go/No
Go
Speculat
e
Tracking
*
Release
Tracking
of Done
created by
the team
Product
backlog is
DEEP
Release
Planning
complete*
End of
Sprint 1
End of
Sprint 3*
End of
Sprint 6*
Stable
velocity*
TG3
TG3.
1
TG3.
2
First
release to
customers*
Second
release to
customers*
MVP:
Minimum
Viable
Product*
Final
release to
customers*
Speculate
& Adapt
phase
complete*
Closure
phase
complete*
TG
Go / No
Go
Tracking
TG4
TG5
set
Planning
Product backlog has
been estimated and
prioritised
There is a high level
plan covering the next 3
sprints Team is ready to
sprint starting with
Sprint Planning for sprint
1
Release
Planning
Tracking
Release
Planning
Go/No
Go
Explore
& Adapt
Explore
& Adapt
Explore
& Adapt
Explore
& Adapt
Tracking
Explore
& Adapt
Tracking
Explore
& Adapt
Tracking
Explore
& Adapt
Tracking
Explore
& Adapt
Go/No
Go
Explore
& Adapt
Go/No
Go
Close out
Go/No
Go
Review product progress
to stakeholders
Review product progress
to stakeholders
When velocity is known
and can be used for
planning purposes
First external release,
not for commercial use:
key features are:
Second external release,
not for commercial use:
key features are:
Product that has enough
features it can be
deployed to end
customers: key features
are:
Final release, product is
ready to go into
maintenance mode
Last sprint is complete;
project can be close
Project can be close; all
pending actions are
close
Tollgate (formal milestone for decision making)
Formal review meetings; dates will be tracked
Milestones will be tracked only i.e. no decision required
Go/No
Go
Go/No
Go
Tracking
Key milestones that will be tracked using milestone tracking tool
Milestone tracking
Milestone Slip chart tool [2] will be used to track milestones marked with * on
a weekly or sprint based depending on the phase of the project (weekly for all
except Explore and Adapt: at the end of each sprint)
Example
3-Jun
3-Jun-07
23-Jun
13-Jul
2-Aug
22-Aug
11-Sep
Oblique
Envision phase
complete (TG1)
Release Planning complete (TG3)
Lift off complete
First release to external customers
Second release to customers
TG3.1: Go/No Go (sprint 3)
TG3.2: Go/No go (sprint 6)
Final release to customers
Speculate & Adapt phase complete (TG4)
23-Jun-07
Speculate phase complete (TG2)
13-Jul-07
Initial performance testing
2-Aug-07
Minimum Viable Product
22-Aug-07
TG3.3: Go/No go (sprint 9)
11-Sep-07
Closure phase complete (TG5)
5. Risk and Issue management
Risks and Issues will be updated on a weekly basis and shared with all
stakeholders
Risk and Issue tracking tool [3] will be used.
Example
RISK ANALYSIS
5
4
3
2
1
0
ISSUE ANALYSIS
5
4
3
2
1
0
6. Assumption management
The project team members must identify and document all of the assumptions
being made during the project planning process, and then on a one by one basis,
identify the risks that exist as a result of each assumption to the project based
on the potential inaccuracies or inconsistencies that the assumption may exhibit.
Assumptions will be managed as Risks using Risk and Tracking tool [3]
7. Dependency management
Release planning sessions, sprint planning meetings and during sprints will
reveal dependencies.
Release planning with other teams as well as scrum of scrums will help negotiate
such dependencies (due date, type, urgency, etc)
Other dependencies will be managed in the table below:
Description
Continuous Delivery
Environment
When by
From sprint 1
Stable platform
From sprint 1
Comments/Risks
Lack of an effective
Continuous Delivery
environment will slow
down development and
prevent us from having
stable velocity
Unstable platform will
mean more time to
identify issues and will
slow down the team
3rd party
8. Communication plan
What
Live demo of
working
software
Sprint reports
Toll Gates
Description
Demo of what has
been delivered
according to the
definition of Done
at the end of the
sprint
Velocity
Release burndown chart
Risks and issues
Test results
Unit test coverage
Number of defects
(inflow and
outflow)
Technical debt
For each gate, a
meeting will be
hold including last
sprint report (if
applicable) and a
review of the
business case.
Decision to
When/Frequency
At the end of each
sprint
Who to:
All
At the end of each
sprint
Stakeholders
See TG dates and
MVP date
Stakeholders
Risks and Issues
Milestone
Tracking
Scrum of scrums
continue (Go) or
cancel (No Go)
the project can be
made at these
meetings
Risks and Issues
on the project
Estimated
milestone dates
Rotating team
members
Weekly
Stakeholders
At the end of each
sprint
Twice a week
Stakeholders
Other team
members from
scrum teams
Minutes of meetings
For meetings with stakeholders, meeting minutes will be recorded using Easy
Minutes [6]
9. Quality Plan
User Stories
User stories will:
Follow the INVEST Model (Independent, Negotiable, Valuable, Estimable,
Sized appropriately and Testable)
Have personas
Have conditions of satisfaction
Have acceptance criteria using specification by example
(Given/When/Then)
Etc
This is not about matching the criteria above that makes a good user story, this
is the quality and appropriate level of information. Hence we will also maintain a
DEEP product backlog (Detailed Appropriately, Estimated, Emergent and
Prioritised).
Definition of Done (DoD)
Creation of the DoD
Team creates their Definition of Done for:
-
User stories
Sprints
Release (to production)
The DoD is approved by the PO and display on the wall
Review of the DoD
The team will review their DoD at the end of each sprint
Example
Design and Testing
Design and testing are aligned with the user stories of the product backlog as per
[7]
10.
Test Strategy
The 4 quadrants
For test planning, we will base our planning on Agile Testing Quadrants [9] and
keeping in mind the success of the project relies on a very collaboration between
all members of the team. Testing is the responsibility of the team, not only to test
engineers working in the team.
The pyramid of tests
From UI Tests (hard to maintain, long to run) to Unit Tests (Easy to maintain,
quick to run) [8].
UI
tests
11.
Functional
tests
Software framework
Unit tests
We will be using Scrum with (as a summary):
-
Sprint Planning
Daily stand-ups
Sprint review
Retrospectives
Sprints will be ? weeks long. Each sprint will finish on Wednesdays 10am.
12.
Release Management
Sprint cycle and release cycle will be decoupled giving the team the opportunity
to release software any time. In general, a release will be made at the end of
each sprint where integration issues will be addressed.
13.
Defect Management
Defects will be adding to the product backlog (if they are not fixed within the
sprint). Defects will be estimated in story points and prioritised among other
defects and user stories.
No points will be given for fixing defects. Points are only for estimation purpose
and will not be added to the velocity.
14.
Roles and Responsibilities
RACI Matrix
Ensure consistency of
scrum practices across
teams
Provide vision and goal for
the product
Provide resource with right
skills and mindset
Prioritize and manage the
product backlog
Remove impediments
Manage the
implementation of the
project plan
Make sure scrum practices
are used and improved
within the team
Create, apply and
continuously improve the
Definition of Done
On time reporting to
management
Define acceptance criteria
Functional
Manager(s
)
I
Scrum
Master
Product
Owner
Scrum
Team
Project
Manager
R/A
R/A
R/A
C/I
R/A
R/A
R/A
R/A
R/A
R/A
R/A
Write acceptance tests
R/A
Ensure quality of the
product
Manage Risks
R/A
R/A
Approve user stories (user
stories meet the
acceptance criteria)
Decide on release date and
goal
R/A
R/A
Note:
1. The above RACI matrix doesnt cover all the activities within the scrum
framework; therefore always check the responsibilities for each role.
2. The RACI matrix may differ per project due to structural and/or
organizational constraints.
Responsible =
Those who do the work to achieve the task. There is typically one role with
a participation type of responsible, although others can be delegated to
assist in the work required
Accountable =
The one ultimately answerable for the correct and thorough completion of
the deliverable or task, and the one from whom responsible is delegated
the work. In other words, an accountable must sign off (approve) on work
that responsible provides. There must be only one accountable specified
for each task or deliverable.
Consulted =
Those whose opinions are sought, typically subject matter experts; and
with whom there is two-way communication.
Informed =
Those who are kept up-to-date on progress, often only on completion of
the task or deliverable; and with whom there is just one-way
communication.
Facilitator =
Helps teams and individuals to continuously improve and understand their
roles within the Scrum framework. They help team members change their
behaviour and act as a coach and a change agent.
15.
Resource Management and Planning
% time allocated and phase
16.
Budget
People
Phase duration (weeks) * Total FTE / 4 weeks (per month): 146.5 man/weeks =
37 man/months
Cost per team member: 50k
Total cost = 50*37 = 1850k
Software
Hardware
Hardware System requirements will be captured under [1].
The cost will be provided:
Trainings
Travels
Miscellaneous
Summary
Type
People
Software
Hardware
Trainings
Travels
Miscellaneou
s
Total
Estimated
Cost (k)
1850
17.
KPIs (Project)
Team Maturity
We will update the checklist [4] on a monthly basis.
Metrics
Velocity will be recorded on a sprint basis
18.
Compliance constraints
19.
Reference
Description
Hardware System Requirements
ID
[1]
Link/File
HW Systems
Requirements v0.2.doc
Milestone Slip Chart tool
[2]
Agile Milestone
Tracker Demo v5.47.xls
Risk and Issue Management tool
[3]
Example Risks-Issues log.xlsm
Scrum Checklist
[4]
Scrumchecklist.xlsx
Lift-off: Launching Agile Teams &
Projects
Easy Minutes tool
[5]
Link: here
[6]
(check where to store Add-In templates
with your version of Windows Microsoft)
EasyMinutesAdd-In
v6.1.dot
Aligning user stories, design and
testing
[7]
The forgotten layer of the test
automation pyramid
[8]
Agile Test Planning
[9]
Agile US DDD BDD
4.jpg
the-forgotten-layer-ofthe-test-automationpyramid
Agile Testing Planning
link
