how to create your project map to reach your destination
Post on 30-Nov-2014
477 Views
Preview:
DESCRIPTION
TRANSCRIPT
Create your project map to reach your destination
October 2012
V 1.3
CAS 2012 Session
2
AGILE EXCELLENCE CENTER
Government TI - A Technology
Xavier Albaladejo is Agile-Lean Coach, IT Governance
expert and member of the everis Agile Excellence
Center. He helps large organizations in being faster
and effective under the principles of Agile and Lean, as
well as to train teams in Scrum and Kanban.
Xavier Albaladejo is coordinator of La Salle Postgraduate
on Agile methods, Certified Scrum Practitioner, founder
of proyectosagiles.org, Agile Barcelona and member of
Agile Spain Board.
3
Index
Product
Map
Inception
Design Thinking
Empathy
maps
User Story
Mapping Techniques for
product and users
conceptualization, as
well as creativity
Determine scope
Identify key
people
Stakehol
der map
Characterize
requirements
Estimate
Identify risks and
mitigations
Domain
Model
Solution maps elaboration
Architec
ture
map
Planning
Prioritization Scheduling
The Product Map technique
explained in this presentation has
been derived from the User Story
Mapping technique
Product
Backlog
Activities for creating a project roadmap
4
Index
1. What will NOT explain now
1. Inception
2. Empathy Maps
3. Design Thinking
4. User Story Mapping
2. Maps
1. Product Map
2. Architecture map
3. Information map
3. Planning
4. Bonus track
1. Stakeholder mapping
2. Short videos of this technique
5
Index
1. What will NOT explain now
1. Inception
2. Empathy Maps
3. Design Thinking
4. User Story Mapping
2. Maps
1. Product Map
2. Architecture map
3. Information map
3. Planning
4. Bonus track
1. Stakeholder mapping
2. Short videos of this technique
6
What we will NOT explain right now Inception
1. Why Are We Here?
2. Elevator Pitch
3. Product Box
4. NOT List
5. Meet Your Neighbors - community project
6. Show the Solution
7. What Keeps Us Up at Night
8. Size It Up
9. What's Going to Give
10. What It's Going to Take
This presentation will cover aspects
related to the green points
7
What we will NOT explain right now Empathy Maps
http://www.bigvisible.com/2012/06/what-is-an-empathy-map/
8
What we will NOT explain right now Design thinking
Empathy to the context of the problem, creativity in the
generation of knowledge and solutions, rationality to
analyze and adapt solutions to the context.
Creative thinking in action
9
What we will NOT explain right now User Story Mapping
Less r
eq
uire
d / o
ptio
na
l
time
Ne
cessity
The backbone
The walking skeleton
time
first release second release
third release -
+
www.agileproductdesign.com / blog / the_new_backlog.html
The Product Map technique explained in this
presentation has been derived from the User
Story Mapping technique
10
Index
1. What will NOT explain now
1. Inception
2. Empathy Maps
3. Design Thinking
4. User Story Mapping
2. Maps
1. Product Map
2. Architecture map
3. Information map
3. Planning
4. Bonus track
1. Stakeholder mapping
2. Short videos of this technique
11
Maps Discover the puzzle
We will develop a product iteratively and
incrementally, so that’s why the first
step is to discover what are the
functional and technical parts of what
the product is made and what are the
most important ones from the point of
view of the customer / user / consumer.
This discovery can be done in a
workshop in the conceptualization of
the project (Inception), in Phase 0 of
Scrum. The functional and technical
“Maps" or high-level models are
elaborated in collaborative way.
Modifications to this puzzle (changing
priorities, adding new parts, removing
others) are done at Product Backlog
Refinement (or Grooming) meetings.
12
Product map Determine the scope
Requirement
To help determine the scope of the
product or project, it may be useful to
display the requirements in a “frame"
that allows visualizing the different
parts of the product (or the scope of
the project). This allows us to identify
the degree of coverage or impact of the
project in each area and see what is not
covered.
Ideally, this "frame" is expressed from
the perspective of different users /
consumers. For example, functional
areas, navigation map of a website,
parts of the product, customer services,
etc.
A two-dimensional spatial
distribution can be used to indicate, for
example, splitting or refinement of
requirements (beyond the basic
functionality) in such a way that they
can be estimated and prioritized
independently, to be developed at
different times (incremental
development).
FUNCTIONAL SUBAREA A1
FUNCTIONAL SUBAREA A2
Requirement
Requirement º
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Baseline
requeriment
Specialized
requirements
Requirement
Requirement
Requirement
Example:
FUNCTIONAL AREA A
13
Product map Identify key people
Requirement
STAKE HOLDER 1
KEY USER Y
It is convenient to identify key people in
the client organization that should
participate in the project to provide the
necessary direction, alignment,
information prioritization, detail and
feedback (stakeholders, end users and
technical staff of the client).
It may also be of interest to identify key
people in the provider organization that
will provide support to the project during
its implementation.
As result, people are associated with
specific parts of the product where they
have more knowledge or direct
participation is required.
Requirement
Requirement º
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Stakeholders and
key users who will
provide information
on prioritization,
detail and
feedback of the
requirements of
this functional area
Requirement
Requirement
Requirement
Example:
FUNCTIONAL AREA A
FUNCTIONAL SUBAREA A1
FUNCTIONAL SUBAREA A2
14
Product map Characterize the requirements
Requirement
FUNCTIONAL AREA A
Different colors can be used to classify
requirements:
Type of functionalities:
Capabilities "out-of-the-Box”
regarding custom development
needs, etc.
Functional Behaviors: Basic vs
refinement / specialization /
alternative paths. This will facilitate
the iterative and incremental product
development, transversal to various
functional areas, with the aim
of starting creating a "walking
skeleton“ and adding new parts
(muscles) to the puzzle, based on
their return on investment or risk to
solve.
User type ("Personas" in the User
eXperience technique).
Requirements that lacks
information or where more
research is required.
Etc.
Requirement
Requirement º
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Out-of-the-box
feature, only requires
parameterization.
Custom
Development needed
Immature
requirement or
where the team
must
investigate, for
example to
know its
feasibility
STAKE HOLDER 1
Requirement
Example:
FUNCTIONAL SUBAREA A1
FUNCTIONAL SUBAREA A2
KEY USER Y
15
Product map Estimate
Requirement
FUNCTIONAL AREA A
Requirement
Requirement º
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Many blue stickers:
costly requirement
STAKE HOLDER 1
As requirements are identified, the
teams asks the Product Owner
/stakeholders / end users questions
on sizing, in order to make a first and
easy quantification of the complexity of
each element.
In order to do this, you can make a first
relative estimate, for example using
stickers: the higher the number of
stickers, the greater complexity, the
greater "size“ of requirement (S, M, L
XL).
Thus, all participants in the workshop
share the same high level vision of what
to do in the project, the value provided
by each requirement, the functioning of
the different parts of the product and the
associated complexity: "When you say
that in this requirement it has to happen
X, are you thinking of "this" and "this"?
Or rather "this" is not needed (which
would be less expensive)?
Example:
FUNCTIONAL SUBAREA A1
FUNCTIONAL SUBAREA A2
KEY USER Y
16
Product map Identify risks and mitigations
Requirement
FUNCTIONAL AREA A
Requirement
Requirement º
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
STAKE HOLDER 1
It is convenient to identify the
requirements that have some kind of
risk. At this point, the team and the
client indicates the objectives /
requirements where they believe there
may be more difficulty for achieve them
(due to dependencies on specific
people in the client organization,
complexity of the requirements, possible
technological difficulties, etc.) and they
made a first mitigation approach.
Many red stickers:
risky requirement
Mitigation
Mitigation
Example:
Risk X
Risk
descript
ion
FUNCTIONAL SUBAREA A1
FUNCTIONAL SUBAREA A2
KEY USER Y
17
Product map Prioritize
Quite simply you can make a first
prioritization, for example by making the
following questions to the Product Owner:
1. What requirements are especially
important for your company /
department / end users/ consumer,
what requirements need to be
"touched" before, or what
requirements you want to be sure the
team understands and to have
enough time to adjust them in case of
misalignment. Thus, when you are
halfway through the project the most
important part of the product will be
developed, there will be needed only
to add less important pieces to an
already stable, tested and revised
product.
2. What requirements are not so
relevant in the project.
With these two simple questions
automatically appear three requirement
sets, within which refine the prioritization
(using more complex techniques if
necessary).
Requirement
FUNCTIONAL AREA A
Requirement
Requirement º
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Example:
STAKE HOLDER 1
Requirement
High
Priority
High
Priority
Low
priority
Low
priority
Low
priority
Spatially separate
post-its into
groups based on
their high or low
priority
Mitigation Risk X
Low
priority
FUNCTIONAL SUBAREA A1
FUNCTIONAL SUBAREA A2
KEY USER Y
18
Product map Global vision
Requireme
nt
FUNCTIONAL SUBAREA A1
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
FUNCTIONAL AREA A STAKE
HOLDER 1 KEY USER AND
Requireme
nt
FUNCTIONAL SUBAREA A1
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
FUNCTIONAL SUBAREA A1
Requireme
nt º
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
Mitigation
Requireme
nt
FUNCTIONAL AREA B STAKE
HOLDER 1
Requireme
nt
FUNCTIONAL SUBAREA A1
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
FUNCTIONAL AREA C STAKE
HOLDER 1
Requireme
nt
FUNCTIONAL SUBAREA A1
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
FUNCTIONAL SUBAREA A1
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt º
Requireme
nt
Requireme
nt
Risk x
Risk X
Mitigation
As a result of the previous steps, at this moment there is a vision of the project scope within a product
“frame” that it is not more a "flat" view, given that priorities have been identified transversely to all product
areas/sections. This will facilitate to elaborate a iterative and incremental development plan.
19
Architecture map Components, risks and no avoidable dependencies
In parallel to the elaboration of the
functional map (the "what") you can
create a technical or architectural
map (the “how") indicating also the
dependencies and integrations
between components, as well as
risks associated to some components,
systems or integrations.
The development order of the technical
components of the solution should be
aligned with the need to accomplish
with the prioritization of objectives /
project requirements. However, you
should also take into account that the
objectives / requirements plan may
be conditioned by technical units that
are difficult to be decoupled, so these
dependencies must be respected in the
objectives / requirements plan.
Component
SYSTEM 1
SUBSYSTEM A
SUBSYSTEM B
Component
Component
Component Compo
nent
2 SET
Component
Component
Component
Component
Component
Component
Mitigation
Dependencies
or integrations
A Risk
20
Information map Domain model
If you are developing an Information System, in addition to functional and technical maps (and in parallel to its
elaboration), it is convenient to diagram, jointly with the client / stakeholders / end users, a simple model
(high level) of entities information and their relationships (Domain Model).
Note that, like the previous models, this information map can be modified and adjusted each iteration and / or
release (e.g. in the detailed requirements workshops and Release Plannings).
21
Index
1. What will NOT explain now
1. Inception
2. Empathy Maps
3. Design Thinking
4. User Story Mapping
2. Maps
1. Product Map
2. Architecture map
3. Information map
3. Planning
4. Bonus tracks
1. Stakeholder mapping
2. Short videos of this technique
22
Planning Scheduling Sprints and Releases
As a first step to develop the Product Backlog and architectural roadmap, requirements and their technical
solution may be distributed on a temporal line, through various iterations and releases, using swimlines by
to split between functional and technical areas. This also allows:
Visualize how from a technology perspective the objectives / requirements will be solved in the project over
time, making dependencies explicit if necessary.
Establishing a walking skeleton, the Minimum Viable Product (MVP) and the order “Pieces” will be added in
different functional and technological areas.
Example:
Requireme
nt
FUNCTIONAL SUBAREA A1
Requireme
nt
Requireme
nt Requireme
nt
Requireme
nt Requireme
nt
Requireme
nt
FUNCTIONAL AREA A
Requireme
nt FUNCTIONAL SUBAREA A1 Requireme
nt Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt
FUNCTIONAL SUBAREA A1
Requireme
nt º Requireme
nt
Requireme
nt Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt Risk X
Mitigation
Requireme
nt
FUNCTIONAL AREA B
STAKE
HOLDER 1
Requireme
nt
FUNCTIONAL SUBAREA A1 Requireme
nt
Requireme
nt Requireme
nt
Requireme
nt
Requireme
nt
Requireme
nt Requireme
nt
Requireme
nt
STAKE
HOLDER 1 KEY USER AND
Time
Risk X
Mitigation SYSTEM 1
STAKE
HOLDER 1 STAKE
HOLDER 1
Product
Backlog
Architectural
Roadmap
Walking skeleton Release 1
23
Planning Real example
Fu
ncti
on
al A
rea
s
Arc
hit
ectu
ral a
rea
s
High Priority
Risk Mitigation
Low priority
Costly requirement
Swimlane by
functional area,
team, etc..
Iterations, quarters or releases (in columns)
24
Planning Swim lanes and relationships
www.enthiosys.com / agile-roadmaps
It can be also interesting to consider additional swim lanes to the existing functional and technical views:
Type of user or market
to be reached
Events that occur
outside the project but
that can impact it
Commitments,
dependencies with
third parties, holidays
Infrastructure needs
25
Planning Visibility of the rationale of decisions and relationships
Threads,
or colored
ribbons
www.enthiosys.com / agile-roadmaps
26
Planning Visibility of the rationale of decisions and relationships
Colors to
identify
dependencies
between
swim lines
www.enthiosys.com / agile-roadmaps
27
Planning Shared global vision
The use of different maps (functional, technical and information) and the systematic use of steps to estimation,
prioritization and identification of risks, provide a project overview. The main benefits are derived from making
this work in a collaborative way in workshop, facilitating to all participants (including client side stakeholders
and supplier team) to maintain conversations, share, align, and get consensus on the initial project vision,
scope, priorities, risks / difficulties and mitigations in the beginning of the project, in a very visual and explicitly
way.
Agile Planning workshop where there are involved customer stakeholders (functional and
technical) and the everis development team, supported by its Agile Excellence Center
(IT Governance, Technology)
28
Planning Progress tracking and change management
Using these maps during the project also allows:
Make a progress tracking on the global scope (easily understand what remains to be developed).
Better visualize the changes and the scope increments (e.g. signaling these situations with colored tags).
Assist in change management, by demonstrating the impact of a change on a product scope "frame"
(on a functional and technical perspective), which facilitates:
Take better decisions, balance the impact of the inclusion of changes in relation to the achieve a
reasonable product on time with sufficient consistency and value. Displaying the impact of changes
helps to consider their opportunity against the incursion into delays on the date originally planned.
Use the concept of "change for free " used in some types of flexible contracts wherein when a new
piece of work is introduced into the puzzle, other pieces of an equivalent size are removed.
Map of Product
Baseline requirements pending
Added or changed requirements
Baseline requirements accepted by the customer
Requirements dependencies
29
Index
1. What will NOT explain now
1. Inception
2. Empathy Maps
3. Design Thinking
4. User Story Mapping
2. Maps
1. Product Map
2. Architecture map
3. Information map
3. Planning
4. Bonus tracks
1. Stakeholder mapping
2. Short videos of this technique
30
Stakeholder mapping Who is impacted and who could put "sticks in the wheels"
Arrows between stakeholders.
Colors to differentiate between
stakeholder types / areas /
departments.
Indicate who are in friendship
(circles of influence / trust).
31
Short videos of this technique
Short videos which shows how to planning a project using this technique (in Spanish with English subtitles) .
Video Description
1 - Identify the scope of the project (7 ') Agile identification of project scope at a functional and technical
level, its complexity and risks in a workshop with the client.
2 - Agile Planning (I) - Ordering (3') Ordering project requirements according to their value, cost and
risk in a workshop with the client.
3 - Agile Planning (II) - Product Backlog (4 ') Agile planning in an iterative and incremental way, in a workshop
with the client. As a result, a high-level view of iterations and
deliveries (Product Backlog) is created.
32
Create your project map to reach your destination Questions
everis.com
top related