Agile and LEAN Project Management

MGMT 292

MODULE 5- LECTURE
AGILE ENVIRONMENT CHARTER AND SCOPE
Agenda
 Implementing Agile : Delivering in an agile environment
Agile
Environment-
Charter and
Scope
Scope: Charter the project and the Team
Every project needs a project charter, so the project team knows: Why this
project matters, where the team is headed, what the project objective is.
For an Agile project, the team needs the project vision or purpose and a clear
set of working agreements. An agile charter answers these questions:
1. Why are we doing this project? This is the project vision
2. Who benefits and how? This may be part of the project vision and /or
project purpose
3. What does “done: mean for the project? These are the project’s release
criteria
4. How are we going to work together? This explains the intended flow of
work
Project Requirements:
What is a Requirement?
A feature/Function definition that satisfies a customer need (and that you build)
“A condition or capability needed by a user to solve a problem or achieve an objective.”
“The project and product features and functions needed to fulfill stakeholders’ needs and
expectations.”
Great Requirement Characteristics
Complete
Correct
Feasible
Necessary
Prioritized
Traceable
Unambiguous
Verifiable
Gathering
Requirements
Techniques
 Brainstorming
 Interviews
 Focus Groups
 Observation
 Facilitated Meetings/ Workshop
 Prototyping
 Document Analysis
 Questionnaire
Inadequate Requirement Results
Characteristics

Insufficient User/Stakeholder Harder to satisfy acceptance

Involvement criteria

What happens if Creeping User Requirements Project delivery off schedule, poor
quality, loss of control and poor
we have team morale.

Inadequate
Ambiguous Requirements Increased costs and rework,
Requirements? unfocused work and difficult to
test or accept.

Gold Plating Project overruns and

unnecessary results.
Minimal or Incomplete Gaps in requirements
Specifications
Project Charter
Reasons to Start a project
◦ Market Demand
◦ Business Need
◦ Technology Advance
◦ Legal Requirement
◦ Social need

“The Charter is the document that Clarifies the

business need, Project Justification, and market
(or customer) requirements, and describes the
product and services to be delivered.”
Principles of Software Development Leadership Ken Whitaker pg 84
Project Charter, What
does it offer the Team?
◦ The need the Project will be fulfilling
◦ Vision for the end result
◦ The Benefit(s) that will come from the project and
for whom
◦ How will we know when the project is complete?
(success criteria)
◦ Expected flow of work and Milestones
Developing The Project Manager/ Facilitator is responsible for conducting a
meeting, discussion or collaboration when developing the Project
Charter as well as Team Charter. This will establish a common
Project understanding regarding Project Objectives, Scope, Requirements
and Deliverables.
Charter:
When the correct techniques are used, it will lead to better
decision making where the solution or conclusion are a mutual
result. It is important for the Facilitator to help all stakeholders
and team members be on the same page to increase “buy-in” for
the Project and Charter elements.
Example of Project Charter (Template
Example)
Sample Project Charter
Charter the Project and the Team
How is the Team Charter different from the Project Charter?
Why would we need a Team Charter, what is the purpose? (Class discuss)

 The Project Charter is a formal document clarifying what Business need the project will be aiming to
create a solution or benefit for. It will highlight the main requirements and who will be benefiting
from the result of the project. The Project Charter is a signed document that gives the authority for
the Project Team to start work on the Project.
 Team Charter purpose is to establish team norms and be able to know how we are expected to work
together. This does not need to be formal but the whole team should have an understanding that is
consistent and established with collaboration from all members. The Team Charter would be found
as part of the Communication Management plan in the Project Management Plan.
Team Charter – What is in it?
The Team Charter should Include:
• Team Values, such as sustainable pace and core hours(working
hours)
• Working agreements, such as what “ready” , “done” means
• Ground Rules, such as one person talking in a meeting
• Group Norms, such as how the team treats meeting times

*There are other possibilities which the Leader/ PM may

add to help the team work to their best ability
Team
Charter
(Example)
Scope
What is Scope?
“Project scope is the part of project planning that involves
determining and documenting a list of specific project goals,
deliverables, features, functions, tasks, deadlines, and
ultimately costs. In other words, it is what needs to be
achieved and the work that must be done to deliver a
project.”
 Once you know who your Stakeholders are, have your Scope
Management Plan to tell you how things will be done and the Charter
has given the authorization for the start of the Project, it is time to
Define your Scope.
 This is when the Team clearly defines what features and functions
make up the full Scope of the Project then establishes what work is
required to accomplish those results to a determined level of
Defining Scope satisfaction (Quality). The project team will consult the stakeholders
when they are gathering and prioritizing the requirements, so that it is
aligned with expectations and to discover all requirements.
*Requirements = Features & Functions  The goal is to have the scope requirements defined in a quantifiable
way so that it can be easily identified as complete.
 The Documents that help describe the Scope are the WBS (Work
*Scope = Work needed to deliver the
requirements Breakdown Structure), Project Scope Statement and the Project
Management Plan

Plan scope management

Scope Statement
What is a Scope Statement?
“A project scope statement is a useful tool to outline
the project's deliverables and identify the constraints,
assumptions and key success factors. The well-written
scope statement clearly defines the boundaries of a
project.”
What goes into a Scope Statement?
Justification (Business Need)
Product Scope Description (Product/ Service/ Result)
Acceptance Criteria (Conditions to be met before it will be accepted)
Deliverables (Objectives) how to reach the Goal
Exclusions (what is NOT in Scope)
Constraints (What parameters do we need to work within?) Cost, time, resources and legal etc.
Assumptions (Something we believe to be true to allow us to continue with work, if becomes
false a change may be needed) always a Risk connected to an assumption.
WBS is a hierarchical decomposition of the work required to
complete the Project.

WBS (Work  Level one is a description of the project as a whole.

 Level 2 is a high level descriptive of the
Breakdown (deliverable/requirement)
 Level 3 are the Work Packages that are required to complete the
Structure) 2nd level.
 Level 4 are the Tasks that are required to accomplish the work
package
WBS- some samples
Output of Scope Management
Scope Management Plan Requirement Management Plan
The Document that explains how Scope will be The Document that explains how
defined, documented and broken down into requirements will be analyzed, documented,
manageable pieces of work over and reported, and managed through the project
maintained through the lifecycle of the lifecycle.
project.
It plans how the team will:
In an Agile project, we accept that there will Define the Scope
be changes to some scope items, we will also Prioritize Requirements
determine how to stay within scope or initiate
Define, Organize, and Develop the WBS
Change Management Process.
Track a Project’s performance though the use
of metrics
Verify and control the Scope
Product Backlog
What is a Product Backlog
List of all requirements (can be identified in Requirements
gathering and found in WBS)
Product owner is responsible for creating and maintaining
Prioritized
Used throughout the project by the Project team
The project Backlog should contain:
Deliverables or deliverable features:
Deliverables:
o IT: customer software features, packaged software installs, servers, router configurations, maintenance manual,
user manual, defect bundles, etc
o Consulting: Key interviews, report chapters, draft report, final report
o Construction: foundation, framing, mechanical, cladding, etc.

 Key business events that require significant preparation by team:

o Analyst presentations
o Trade shows
o Architecture review board presentations
o Project Review Board submissions
o Etc
Backlog Preparation
 The backlog is the list of all the work, presented in story form, for a team
There is no need to create all of the stories for the entire project before the works starts
 How much is enough?
 Only enough to understand the first release broadly and then sufficient items for the next iteration

Product owners might produce a product roadmap to show the anticipated sequence of
deliverables over time
 The product owner replans the roadmap based on what the team produces.
Product Backlog Refinement
Backlog Refinement
The project starts with high level Requirements
When planning the next iteration, the requirements are broken down into smaller parts. (small
enough to begin work and to assign responsibility)
 1-hour discussion midway through a 2-week iteration
Multiple refinement discussions for iteration-based agile teams
User story:
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 template:
As a <type of user>, I want to <some goal and type of action> so I can <some reason, have this
benefit>
How to Write a User Story
“A set of well-defined, prioritized user stories can help you
articulate the functionality of your product using ‘plain
English’ — with no technicalities and implementation
details.”

User Stories:
• Encourage participation by non-technical members.
• Help to achieve cross-team clarity on what to build, for
whom, why, and when.
• Assist in defining the entire product
User Story (Guidelines)
User Stories does not = Tasks
Stay High Level
Understand Users (persona)
Think as a User
Think Big
Use Epics to simplify planning
 Epics are large user stories that can be broken down into a
number of smaller user stories
Prioritize – Don’t Discard
Setup for success – not just acceptance
Organize with naming and Categorizing
Don’t forget the Specs
What is next?
 Class activity M5
Applied Project, Group Assignments Review