how to create your project map to reach your destination

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.

http://agile-barcelona.org/

http://agile-spain.org/

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. Inception

2. Empathy Maps

3. Design Thinking


2. Maps

1. Product Map

2. Architecture map

3. Information map

3. Planning

4. Bonus track



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

http://www.agileproductdesign.com/blog/the_new_backlog.html

10

Index


1. Inception

2. Empathy Maps

3. Design Thinking


2. Maps

1. Product Map

2. Architecture map

3. Information map

3. Planning

4. Bonus track



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


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



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:



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:



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



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



KEY USER Y

18

Product map Global vision

Requireme

nt


Requireme

nt

Requireme

nt

Requireme

nt

Requireme

nt

Requireme

nt

Requireme

nt

FUNCTIONAL AREA A STAKE

HOLDER 1 KEY USER AND

Requireme

nt


Requireme

nt

Requireme

nt

Requireme

nt

Requireme

nt

Requireme

nt

Requireme

nt

Requireme

nt


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


Requireme

nt

Requireme

nt

Requireme

nt

Requireme

nt

Requireme

nt

Requireme

nt

Requireme

nt

FUNCTIONAL AREA C STAKE

HOLDER 1

Requireme

nt


Requireme

nt

Requireme

nt

Requireme

nt

Requireme

nt

Requireme

nt

Requireme

nt

Requireme

nt


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. Inception

2. Empathy Maps

3. Design Thinking


2. Maps

1. Product Map

2. Architecture map

3. Information map

3. Planning

4. Bonus tracks



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


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


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

http://www.enthiosys.com/agile-roadmaps



25

Planning Visibility of the rationale of decisions and relationships

Threads,

or colored

ribbons





26

Planning Visibility of the rationale of decisions and relationships

Colors to

identify

dependencies

between

swim lines





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. Inception

2. Empathy Maps

3. Design Thinking


2. Maps

1. Product Map

2. Architecture map

3. Information map

3. Planning

4. Bonus tracks



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.

http://www.youtube.com/watch?v=_PWuSK2yiM0

http://www.youtube.com/watch?v=6_av1V2Lx8U




http://www.youtube.com/watch?v=671iQ7uQmNs





32

Create your project map to reach your destination Questions

everis.com