AGILE Bea Dring &

Hkan Kleijn

INCEPTION
The Loop Approach
ry
s tiety r
a l o
Mquearat
n
ge

Pu
fo rp
os

cu
e

s
bu
il
de
r

to tYour
he tri
cusultimp
exp tome ate
erie r Aut
BRAINPOWER nce cre on
ativ o
ity my
boo
s
ter
 BRAINPOWER
Aut
to tYour cre on
ativ o
ity my
he trip
cusultim
boo
s
ter

exp tome ate

erie r
nce

INTRODUCTION
WHY THIS BOOK?
As Agile coaches, we have noted that some problems re-surface
again and again when it comes to adopting or transforming to an
agile way of working. Therefore, we would like to share our experi-
ences from various different customer projects.

To help organisations to handle these challenges, we base our strategies on

the following questions:
How do you get started with product and release planning?
How do you accelerate your requirements work?
How do you scale agile to a multiteam and distributed context,
and apply different strategies for agile adoption?
How do you wrap a minimal project structure around agile
teams in a non-invasive way?
2
 Pu
fo rp
os

cu
e

s
bu
il
de
r

e ry
t
s ity r
Mqauearlato
n
ge

In this first of a series of books covering different themes, we present an

extensive coaching tool box regarding agile inception work that we want
to share with others. Hopefully it will help you, the reader, to invent new
creative mistakes instead of re-doing ours.

Questions and feedback are welcome!

Beatrice Hkan
beatric.during@softhouse.se hakan.kleijn@softhouse.se

Web: http://en.softhouse.se/info
http://softhouseeducation.se/shop
Twitter: @bea73
3
 INTRODUCING THE LOOP APPROACH

G O !
This book is about the pre-release planning stage. In an Agile
context, this work collapses the boundaries between the aspects
of business development and project management that haunt
conventional, phase-based project life cycles. It contains strategies
and techniques for accelerating business level output needed to
initiate Agile releases and/or projects.

The more conventional discussions around this tends to be a very com-

plicated tangle of perspectives, techniques and buzz words: pre-studies,
business cases, business requirements from the perspective of project
management, product management as well as from a pure line manage-
ment/budgeting, resource planning perspective you name it! And more
to the point how this is done in an agile context, are there any equivalent
practices? Apparently, a more structured and rugged model could be of
great use!

Introducing The Loop Approach in the following pages, we will share our
experiences on what we feel is a relevant tool box with different strategies
for combining techniques to use for the Agile Inception work. It all boils o!
down to this: Go & D
o!

D Y - S TEADY
GO!
Go & D

EA
GO!
R

Loop 1: Ready, steady, go! Loop 2: Go!

Purpose and fit: This loop use collabora-
tive agile techniques to generate a similar
outcome as a traditional feasibility or pre-
study. The time box of 510 days consists of
a series of accelerated and cross-functional
workshops to produce critical business level
output with emphasis on product scope.
Who participates: Development team and
business stakeholders.
Techniques: Impact mapping, product vision,
user personas, customer lifecycle/customer
journey, use case modelling, business model
canvas, product roadmap, release planning.
READY-STEADY Go & Do!
GO! 4
Purpose and fit:This loop use collaborative
agile techniques to generate a high level
backbone release plan with emphasis on
business viability. The time box of 3 days
consists of a series of accelerated and cross-
functional workshops to produce critical busi-
ness level output that supports fast, strategic
decision-making regarding upcoming release
efforts.
Who participates: Development team and
business stakeholders.
Techniques: Business model canvas,
customer life cycle/customer journey, release
planning.
Go & Do!
 GO!
HOW TO USE THE LOOP APPROACH
By using a combination of techniques executed via a series of
workshops, we can engage different groups of people in the or-
ganisation depending on what type of change we are involved in.
Each loop has a specific scope for creating business level output.
As Agile Inception strategies, the loops work for single agile teams
as well as scaled environments where multiple team collaborates
on developing products and services.

As always, you dear reader! have to do your homework in contextual-

izing the ideas in this publication to fit your organisation and your needs.
This book doesnt present silver bullet solutions but hopefully a burst of
inspiration and help in accelerating the business output side that an agile
execution needs in order to do the right thing right and fast. Instead, this
will hopefully help you put together the loop you need for your current ef-
fort. And the loop you experience will probably not exactly fit the next effort
you get involved in. This is continuous learning and improvement and it is a
good thing.

Go & Do! Go & Do!

Loop 3: Go & Do!

Purpose and fit: This loop use collaborative
agile techniques to explore impact by gen-
erating prototype(s) to get customer insight
and hence to validate business viability.The
time box of 5 days consists of a series of ac-
celerated and cross-functional workshops to
produce critical business level output as well
as first prototype.

Who participates: Development team,

business stakeholders, customers.
Techniques: Impact mapping, prototyping,
Business Model Canvas.
The word inception here indicates that we
are starting something, like planning a
major product-related effort of some sort.
Hence, we are not referring to inception in
the RUP sense of the word.

5
 y,
1
OP
LO

d
a y,
e
R ad
e MPACT M
StGo!

I
APP
on

ING!
i
vis
Bu
m sin

t
uc
o
ca de
od
nv
Pr PR
OD
UC
a
TR
OA
D M

LOOP 1:
READY, STEADY, GO!
FOR an organization delivering complex services through a multi
channel customer lifecycle, WHO HAS a need for crucial business
level output in order to facilitate a Go/No Go decision before
proceeding with release planning and project chartering, Ready,
Steady, Go IS AN agile collaboration loop, THAT delivers a busi-
ness model and a story map, UNLIKE a traditional feasibility study,
READY, STEADY, GO delivers in 510 working days

This loop use collaborative agile techniques to generate a similar outcome

as a traditional feasibility study. A pre-condition to succeed with the loop
is to execute the techniques with a collocated, cross-functional team and
with key stakeholders available in parallel for fast answers and validation of
results.

When to use
Loop 1 is used when the answer is yes to any of these questions:

Is your product context a complex service with many features delivered

through a multichannel customer life cycle?
6
 eCycle
e r Lif
tom
Cus ney
ur
me r Jo
to
Cus
ne
el ss
as
M
AP
Rel
eas
e pl
ann
ing

Do you need to catch crucial up front business data in order to facilitate

a Go/No Go decision before entering release planning?
Do you have executive decision making stakeholders asking for
pre-studies and heavier up front requirement specs in order to approve
the effort then this loop might fit your needs.

Time box
510 working days.

Lets get into the loop

It is human to try to understand, why are we going in this direction? Why are
we doing this product or why are we running this project? These questions
need an inspiring and communicative answer in order to get buy in.
7
IMPACT MAPPING
Mind mapping is a suitable technique to boost creativity and help you to
find out, and also to remember why, through a connected visualization.
A good practice is to build mind maps and impact maps with stickers on a
white board. This format lets everyone in a team participate and it is easy to
make changes.

Impact mapping was created by Gojko Adzic as a means to shift the

conversation from what is needed to why we want to achieve a certain type
of business goal or effect and identifying the impact needed in order to
reach the goal. The model is about understanding the behaviors that need
to change among key stakeholders in order to achieve a sustainable result.

What?
How?
What?
Who?
How? What?

What?
Why?

What?
How? What?
Who?
How? What?

What?

As such an Impact map is a specific mind map format, which organizes

your ideas in a logical structure deriving the minimal amount of
capabilities (what) needed tied together with strategies on how to facilitate
the changed behavior (how) among key stakeholders (who) that need to be
impacted in order to achieve the goal (why).

First, identify the goal, why is this important?

Next step, who are the stakeholders/actors who we need to influence
and impact (who can block it or support the goal)?
What are the actual impacts we need the actors to engage in as a
desired change of behaviour in order to progress towards the goal?

8
 Finally, what organizational activities and/or software capabilities,
in short the deliverables that will facilitate the impacts being achieved?
At this point you can focus on finding the shortest path through the
map in order to execute the goal. Applying this strategy gives you the
least wasteful first view of work needed!

Impact mapping may look straightforward but an experienced facilitator

will certainly be worth the effort.

We think Impact Mapping is a good way to initiate the Inception work since
it is a fast, structured way to identify the game play, the value strategy, that
we need to agree on before we start to work more product and capability-
centric. Lets not forget though that already at this stage you will have
homed in on the high-level capability areas that will drive your impact,
were just not spending time just yet to break the capabilities down to a
more estimable level at this point.

PRODUCT VISION
It is now time to transition from Why to What and become more product and
capability-centric. Impact mapping delivers a high level view of the right
capabilities needed, to ensure impact, and to reach the goal intended, i.e.
the value strategy. This goal and its related capabilities might need further
elaboration to describe a product and its desired end state or it might need
to be validated from a different angle involving additional stakeholders.

The Product Vision step is part of the planning and collaborative practices
of XP, eXtreme Programming to initiate the product effort identification.
Typical for XP is the playful, collaborative and accelerated nature of the vi-
sion activities. Lets look at our favorites.

9
 10-15
subfeatures
on back

Pr
naoduc
me t
1:
2:
3:

T
E
K
R
A
M
Product Box
Imagine your product is offered to the market in a box. How would you
design it?

Cover Story Quotes

Sidebars

COVER
STORY
HEADLINE!
HEADLINE!

Feature Articles Photo

Cover Story
Imagine your product as a cover story for a published magazine. What
would it look like?

10
Typical for these vision activities is to time box them to half a day to build
actual physical end result. Also typical is to encourage the build of several
results and during the session narrow down to one end result (product box
or cover story) after a structured discussion in the team. Sometimes, tech-
niques like dot-voting and fist of five polling is used to encourage participa-
tion, contribution and to achieve consensus.

Elevator Pitch sentence structure:

FOR (target customer) , WHO HAS
(customer need) , (product name)

IS A (market category) THAT

(one key benefit) UNLIKE (competition)
THE PRODUCT (unique differentiator)

Elevator Pitch
Imagine a time slot of 30 seconds to sell and/or inform someone about your
product. Which information is essential to deliver a clear message? The
Elevator Pitch is a good way to conclude the Impact and Vision work, into a
distinct summary of the product effort you are about to initiate work on.

Here are two different examples of an Elevator Pitch from projects and
teams we have been coaching:

For projects and agile teams who need to plan, execute and monitor their
work Eutaxia is a cloud based group collaboration tool that offers easy co-
ordination of individual and team todos in a project. Unlike Project Place or
Microsoft Project Eutaxia provides a dynamic search interface with tagging
for customizing the tracking of todos in your projects
(courtesy of the Eutaxia team, http://www.eutaxia.eu/)

For language implementers who need to tackle compilation bottlenecks

in their programming language the RPython JIT compiler framework
offers a flexible backend and frontend support for getting JIT support
into your language environment. Unlike language specific, hardwired JITs
RPython gives you a fast Just-In-Time compiler for your favorite language
for free
(courtesy of the PyPy team, www.pypy.org)

11
 Elevator Pitch can benefit from being produced in a similar fashion as
the vision activities, that is everyone builds their own draft version and
the team collaborates on narrowing down the options and discuss their
different interpretations and end up with one clear agreement on what the
product effort will offer and for whom.

A brief word of advice if your product effort is an enhancement of an

already existing product and you find it difficult to differentiate towards
competitors, you can compare the benefits against the previous version
of your product. Sometimes, you may also need to refer to a well known
quality product with LIKE product x, our product etc.

At this point we know why we need to do what on a high level. Before we

dive into the product capabilities in a more detail, we focus on the target
group and their needs by creating user personas, which facilitate a strong
emphasis on the customer experience.

MOI?
Xxxx Xxxx

Xxxx Xxxx
Xxxx

Xxxx
Xxxx
Xxxx

Xxxx
Xxxx Xxxx

User Personas
Use the power of a persona to understand your customer segment and
establish a strong design target. A user persona is an archetypal descrip-
tion of a fictional persons characteristics, demographics and goals that
support planning of product capabilities and facilitate making trade-off
decisions with user personas acting as the Voice of The Customer. It is

Use user personas, archetypal descriptions of fictional persons character-

istics, demographics and goals, to zoom in on your customer segments.

12
13
good to produce 24 user personas in order to capture the key customer
characteristics among the target group which will illustrate the different
trade-offs needed to be done in terms of UX decisions as well as decisions
regarding global conditions and constraints on the product effort we are
planning to initiate.

User Personas can contain lengthy descriptions, at this stage we use a first
initial mock up of the User Personas that can be finalized after loop 1 is
concluded.

A word of advice do not mix up user personas with the less informative
actor description, which represents a specific user role of a product, such
as online customer.

At this point we have concluded a fast, small and skinny journey, having
achieved a high level consensus on why (the goal and impact needed) we
are planning to do what (the product vision with key capabilities) for whom
(target group/actors and user personas).

Now it is time to take the what and dive deeper into what capabilities are
needed in order to meet the product vision. We need to ensure we have
breadth-before-depth on which part of the product, and the product
elements that are affected, before we start to write our user stories.

Customer Life Cycle

When trawling for product capabilities during the inception work we
recommend using a Customer Life Cycle model to identify the high-level
customer interactions that the product experience need to comprise.
Customer Life Cycle is a model coming from the Customer Relationship
Management (CRM) domain, Sterne and Cutlers original model is based on

14
five basic steps: reach, acquisition, conversion, retention, and loyalty.
We usually use this model to go from product vision and key product at-
tributes to actual high level capabilities, our hybrid model below is more of
a business requirement related tool and we have used it in various different
customer projects, mostly within the IT and telecom domain.

Awareness Research

End Purchase

Payment Receive

Upgrade Experience

Customer Life Cycle, CLC

It is a good model for understanding the current state of the product (if you
have one that is) and to visualize where our impact mapping high level ca-
pabilities will appear in the overall customer experience. A Customer Life
Cycle model also facilitates value prioritization when having to make trade-
off decisions between adding new product capabilities or adding capabili-
ties to the process/systems enabling the customer experience, a decision
that is related to where your product is in its Product Life Cycle.

Use mind-mapping and stickers as the way to model the capabilities and
where they need to appear in the CLC model. In some teams we use colour-
coded stickers to visualize and separate the current state capabilities and
the desired new capabilities.

Still on a high-level we have now expanded our what to potentially cover

more than just product capabilities. We are still focusing on breath-before-
depth meaning horizontal coverage rather than vertical depth of details.
Lets look at some closely related techniques that help us to explore the
what and minimize the risk of omission by mistake.

CLC and Channels

Customer life cycles can be, and are often, further divided into (communi-
cation) channels, e.g. retail store, web shop etc. Again, depending on where
your product is in its life cycle the main focus of your upcoming product ef-
fort might very well be more customer life cycle related rather than purely
product related. It is important to keep a customer-centric view because
the customer does not differentiate between the actual product capabilities
and the supporting processes.
15
Use a customer journey
to visualize the complete
customer experience

)o
>
eb

Customer journey
A customer life cycle describes high-level customer interaction, while a
customer journey portrays the complete customer experience by visualizing
every touch point with a product (or service). Use customer journey
mapping to identify capabilities (and conditions and constraints) at each
touch point. If the customer life cycle has been divided into channels, one
customer journey map per channel (or color coded stickers) is required.

The touch points are the tangibles that make up the total experience of
using a product (or service). Touch points can take many forms, from
advertising to personal cards, web- mobile phone- and PC interfaces, bills,
retail shops, call centers and customer representatives.

A customer journey is basically a very high level, touch-point driven flow

chart showing the customer main steps and how it connects to manual
and/or digital process support in each main step (ie what devices are
involved). Again, context is key.

At this point in time we might have spent 34 days in total producing crucial
output. We might have a draft list of 30 and not more than 50 high level
product attributes, mainly capabilities (ie features) but also conditions
and constraints (non-functional aspects needed), maybe written in user
story format. We are still in What-mode but now its time to drill down and
decompose parts of our larger product attributes that we know might be
crucial in the earlier stages of the upcoming product effort we are planning
to execute.

16
 Shop Online
Payment
Processing
View Products System

Purchase
Products
Manage Fulfil
Customer Order
Online
Customer information

Compare Warehouse
Clerk
Products
Report
inventory
Manage
Product
Report Manage
Product inventory
Sales
Marketing Warehouse
Administrator Manager

Use Case Diagram

Use case diagrams have been around for a while, it is one of several (many)
modeling techniques in UML but we are not using them for modeling
the solution, we are using it to do a fast sketch of the capability that we
need to decompose. We agree with Alistair Cockburn on the value of still
using use cases (see his blog post from 2008 http://alistair.cockburn.us/
Why+I+still+use+use+cases), we are goal-centric, we are user-centric and
we get context that will help us understand how a single smaller capabil-
ity (ie feature possibly written in user story format) can co-exist with other
capabilities to achieve a goal. Whats not to like with it?

What are Use case diagrams? Use case diagrams provide a simplified and
graphical representation of an actors interaction with a product, i.e. what
the product must actually do. If the product vision represents the overall
goal of a product, each capability (oval, we recommend writing them in the
user story format) in the diagram represents a goal of an actor (straw man).

NOTE: In comparison with a customer life cycle/journey, which de-

scribes the total customer experience, a use case diagram focus on
product capabilities (features) and actors, and it details a sub-part of
the customer life cycle/journey. A customer journey can be seen as a
set of glued together use case diagrams, one per customer life cycle
phase. The main difference is their information perspective, customer
journey displays the information objects (touch points), while use case
diagram displays capabilities (features) and actors.

17
Identify actors, system and services (= subject)
Based on the product vision, identify actors by asking the following three
questions;
1. Which actors are on such a product?
2. Which actors could be?
3. What other systems, services (or actors) do we need to
communicate with?

Please note that you you have lots of actor-data already produced in your
Impact Map, your user personas and your customer life cycle!

Identify goals (= verb and object) per actor

Based on the identified actors, capture their individual goals by asking
questions in the following style;
1. Why does an online customer use the product?
2. Why would the payment processing system have an interface with us?
3. Write goals as; Verb and Object, e.g. View Products.

A word of caution though. This modeling technique is focused on identifying

the goals ie the capabilities needed for the actor/role to achieve their goal.
It does not model the need for non-functional attributes such as conditions
and constraints. You have to add them to your growing list of product
attributes needed to facilitate the impact needed to make your product
vision come alive. Again you should be able to trace back many of your
actual goals (use cases) to you Impact map and customer life cycle.

User Story Decomposition

These initial capabilities (written as user stories i.e. epics at this state) are
too large to be implemented. They must to be decomposed into several
sub-stories, i.e. additional user stories of greater detail. Decomposition
continues until user stories are detailed enough for implementation. All
stories must also have an estimation, preferrably using relative estimating
techniques such as ideal engineering time or story points.

Please note that story decomposition is an ongoing activity in agile

product development. A rule of thumb is to stay one iteration ahead of the
implementation iteration. Right now we are creating output needed for an
upcoming release plan, when the release have started we apply the rolling
wave principle of one iteration ahead (so called product backlog refinement
or grooming the backlog).

The reason why we have use case diagrams is that this loop is designed
for teams and organisations that need to do a bit more up-front detailing
as part of planning the product effort ie the release/releases. Use case
diagram modeling is a fast, visual and context-supporting technique. When

18
doing the decomposition work, it helps the development to cognitively
zoom-in and zoom-out when the volume of user stories start to increase.

Now we have a larger set of capabilities that we can trace directly back
to the high level capabilities needed to support the impact we trying to
achieve. At this point we can start to create the canvas for the business
context that the upcoming product effort will service and we can do this
because we have a very good overview of the decomposed user needs and
how they cooperate from the actors and users perspective.

Business Model Canvas

A business model canvas explores the viability for a product idea,
commonly by smoke testing prototypes, e.g. landing pages against
identified customer segments. The main purpose is to create a valid
business model or else to kill early.

Key Key Value Customer Customer

Partners Activities Propositions Relationships Segments

Key Channels
Resources

A persona clarifies your customer segment. A product vision sharpens your

value proposition. A customer life cycle / journey help you understanding
customer relationships, channels, needed key resources and potential
partners. A use case diagram identifies high-level product capabilities
(features) and when needed, how to decompose them to smaller items.
So at this point you have many of the key attributes of the Business Model
Canvas and can focus on a collaborative dialogue, painting the business
canvas together and fill in the gaps.

If yours is a product effort from scratch we recommend that you and

your team build a Business Model Canvas. And even if you are working
on planning the next larger step in your Product Lifecycle of an existing
product it might be beneficial to try out this technique in order to really
narrow down the most critical steps needed to achieve a tangible business
result.

19
The techniques presented so far in this loop have yielded crucial output
that the Business Model Canvas template use as input to integrate and
construct an initial BMC. After populating this information it is time to
start thinking about cost structure and revenue streams. Then design a
hypothesis and formulate a quantifiable metric. Finally create a prototype
and generate insights from your customer segment. We view the BMC
as a the main technique to make your Impact map come alive. The other
techniques presented in this loop so far are supporting techniques, mostly
because many organisations might need a more thorough understanding of
the capabilities needed in order to be able to create a BMC and agree on it.

Now that we have integrated our business output and our decomposed,
quite large set of product capabilities (user stories), into a business value
model we can start to think about a very high level build order based on our
value strategy, the Product Roadmap.

Product Roadmap
A product roadmap states planned major releases, typically one year ahead,
their goals, key features, and metrics. The roadmap goals are hypotheses.
The work we have done, and the business output we have created so far
should mean that we are able to make qualitative assumptions and not wild
guesses about the planned product efforts ahead.

Acquisition: Activation: Retention Acquisition

Free app, Focus on New segment
Goal
limited in- in-app
app purchases purchases

Basic Purchase Additional New

functionality new outfit skill levels characters
Feature

Downloads: Activations, Daily active Downloads

Metric top 10 game downloads players
app

Timing 1st quarter 2nd quarter 3rd quarter 4th quarter

Release Version 1 Version 2 Version 3 Version 4

A product roadmap connects business model with product capabilities and link
market insights with product releases

20
 Version 1 is focused on user acquisition
(Minimum Viable Product)
Version 2 on activation and revenue generation
(Minimum Marketable Product)
Version 3 is about retaining existing users
(Minimum Marketable Feature)
Version 4 targets a new segment and tries to acquire new users

A product roadmap connects the business model with our extended list
of product capabilities, conditions and constraints (possibly existing in a
product backlog as a sorted list of product backlog items, PBIs) and link
market insights with product release/releases.

THE RELEASE PLAN

Now we, in the development team, have everything we need to collabora-
tively build our Release plan. This is the last step in the loop and now we
look into and give initial time and costs estimates for the upcoming product
efforts being planned (ie release/releases). We recommend User Story
Mapping as a great way to visualise the work needed as well as identifying
your release strategy.

User Story Mapping

Arrange your capabilities ie your epics and decomposed user stories into
a structured model to visualize the product backlog as the total use of
your product including each actors usage perspective. A user story map
(together with product vision) tells the whole story of a product (or service).

Epics are arranged from left to right in time sequence order. Each epics
break down into several smaller user stories. A high position indicates they
are absolutely necessary, lower position indicate they are of less business
importance.

Release Planning
The users stories placed high on the story map describe the smallest
product (or service) that would give end-to-end functionality and deliver
the business value declared by a release goal. This functionality should be
released first, before anything else is worked on. Draw a line across the
user story map to visualize the user stories of product version 1.

A Release Plan specifies the capabilities ie user stories of each product

version and date for release. It is more detailed than a product roadmap but
still just a time based backbone of your user story map. This time plan is
suitable for mapping in long lead time items such as purchases of equipment
and external deliveries into the project in parallel with the planned iterations

21
in the release/releases. It is also a useful visual to use with business
stakeholders that are used to the more Gatt-like view of projects.

Please note that we are not promoting a big plan up front with a full
breakdown up front of all product capabilities/user stories. A release plan
has more decomposed iteration candidates for the first iteration, the rest
of the release candidates stay on a higher level of detail and we use rolling
wave planning while working on one iteration to prepare and decompose
upcoming iteration candidates during the release as work progress.

User User User

Role 1 Role 2 Role 3

Epic1 Epic2 Epic3

Story 3(2) Story 5(5) Story 8(1) Story 11(8) Story 17(1) Story 19(2)

Story 2(1) Story 6(5) Story 10(2) Story 12(1) Story 16(3) Story 20(2)
R1

Story 1(5) Story 4(8) Story 9(8) Story 13(2) Story 15(5) Story 21(3) R2

Story 7(3) Story 14(3) Story 18(5)

22
Split initial product version into iterations and derive duration
A pre-requisite for release planning is the expected velocity at which user
stories are implemented and the iteration length. It is also common to set a
iteration cost (based on # of individuals in the team and their allocation)

Velocity = story points/iteration (25).

Iteration length (4 weeks)
Iteration cost (10000 $)

Summarize the total number of story points for release of product version 1
(75) and split it into iterations based upon the velocity (75/25 = 3).

Release of product version 1 will be delivered in 3 iterations

Release of product version 1 will cost 30000 $

Derive duration by calculating number of iterations x iteration length (3x4 =12

weeks).

Release of product version 1 will be delivered in 12 weeks.

Revisit the user story model after every iteration

As user story effort (story points) is estimated and velocity (story points/
iteration) is guesstimated, initial release plans will be revisited and
adjusted in accordance with the real measured velocity once iteration
execution starts.

The user story map can be used as-is, but it is commonly split into product
backlog, release plan and iteration plan for practical reasons, such as,
version control, information sharing and storage.

Congrats, you have concluded loop 1, you have now a Release Plan which is
based on a Product Roadmap and connected to a Business Model Canvas,
which can be traced back to your Impact Map and Product Vision. During this
journey you have dived deeper into the target group and their statement of
need, the involved user personas and the large number of capabilities that
will enable their goals and hence your impact and business goals.

23
 C
u
s

cu
U jo
s
d e t
o

st
e r u
c r m

om
o s n e
m to e r

er
y
p r
o y

li
s

fe
it
io

cy
n

cl
e
LOOP 2:
GO!
FOR an organization delivering new or enhanced services through
an existing customer lifecycle, WHO HAS a need for fast business
viability and story prioritization, Go! IS AN agile collaboration
loop, THAT delivers a user story map and a release plan, UNLIKE a
traditional business initiative, GO! delivers in 3 working days

This loop generates a user story map and a product roadmap after a quick
business viability check. Loop 2 is suitable for teams and organisations that
are capable of fast, strategic decision-making based on a rough high-level
backbone release plan.
A pre-condition to succeed with the loop is to execute the techniques with
a collocated, cross-functional team and with key stakeholders available in
parallel for fast answers and validation of results.

When to use
Loop 2 is used when the answer is yes to any of these questions:

Is your product context in need of new or enhances services through an

existing customer life cycle?
Do you need a high level look ahead plan that covers multiple iterations
of the release in order to coordinate your development efforts with
delivery organisation?
Do you need to enhance your agile planning game with a tighter
connection to business value delivery then this loop might fit your needs.

24
 eg
sn
a i
e n
l n

as
ea
Rl
v
p
c an

l
de
2

mo
o p
ne
ss
Lo !
o
si

G
bu

Time box
3 working days.

Lets get into the loop

It is easy to generate an awful lot of splendid ideas while it is hard to sift
out that very special idea with high business potential. Do some people use
a magic wand or do they hide a crystal ball in their closet? As a matter of
fact, there is a tool that works for real! Mobilize your brain power and get
ready for business model canvas, an ingenious one-page concept that will
help you dig for gold.

25
Business model canvas
Starting with the Business model canvas helps the team to focus on do the
right thing right and fast. Many agile teams start their journey being busy
with the do the right thing right and fast, starting the loop with a Business
model canvas puts emphasis on the value model and finding the right value
strategy which is at the heart of agile!

A business model canvas explores the viability for a product idea,

commonly by smoke testing prototypes, e.g. landing pages against
identified customer segments. The main purpose is to create a valid
business model or else to kill early.

Key Key Value Customer Customer

Partners Activities Propositions Relationships Segments

Key Channels
Resources

If yours is a product effort from scratch we recommend that you and

your team build a Business Model Canvas. And even if you are working
on planning the next larger step in your Product Lifecycle of an existing
product it might be beneficial to try out this technique in order to really
narrow down the most critical steps needed to achieve a tangible business
result.

Start with the Customer Segments and Value Proposition to have a good
customer and user-centric focus when identifying the values unique to
your planned effort. If you are planning the next major effort on an existing
product you still need to capture the Value Proposition in comparison to
your competitors but you might also want to emphasise how this next
release will sharpen the value proposition further.

With this product and customer-centric core identified you can add
another layer to your model which would be to discuss and home in on Key
Resources, Key Activities and Key Partners who would enable the delivery
of the value proposition to the Customer Segments.

26
After populating this information it is time to start thinking about cost
structure and revenue streams. Then design a hypothesis and formulate a
quantifiable metric. Finally create a prototype and generate insights from
your customer segment.

Please note that at this point in time we have not spent time on under-
standing the actual product capabilities that will help make the BMC come
alive we are starting to head in that direction though!

When we do the business model, we typically need answers to the following

questions; What channels do we need? Who needs to be involved? How
does our channels relate to customer relationships and key resources?

This essential information is sometimes hard to grasp. We often need to

look from another perspective to get it right. Looking into our customer
life cycle is handy way forward and gives us a good basis for a more user-
centric perspective during the planning work.

Customer Life Cycle

When trawling for product capabilities during the inception work we
recommend using a Customer Life Cycle model to identify the high-level
customer interactions that the product experience need to comprise.
Customer Life Cycle is a model coming from the Customer Relationship
Management (CRM) domain, Sterne and Cutlers original model is based on
five basic steps: reach, acquisition, conversion, retention, and loyalty.

We usually use this model to go from a Business model canvas with a Value
proposition to actual high level capabilities, our hybrid model below is
more of a business requirement related tool and we have used it in various
different customer projects, mostly within the IT and telecom domain.

Awareness Research

End Purchase

Payment Receive

Upgrade Experience

Customer Life Cycle, CLC

27
It is a good model for understanding the current state of the product (if
you have one that is) and to visualize where our impact mapping high level
capabilities will appear in the overall customer experience. A Customer
Life Cycle model also facilitates value prioritization when having to make
trade-off decisions between adding new product capabilities or adding
capabilities to the process/systems enabling the customer experience, a
decision that is related to where your product is in its Product Life Cycle.

Use mind-mapping and stickers as the way to model the capabilities and
where they need to appear in the CLC model. In some teams we use colour-
coded stickers to visualize and separate the current state capabilities and
the desired new capabilities.

Still on a high-level we have now expanded our value proposition to

potentially cover more than just product capabilities. After some struggling,
prioritization, voting and decision making, the business model is finally
good enough and agreed. We do understand on high level, what capabilities
our service must deliver in order to make the value proposition come alive,
but how should it really work?

Lets bring on the customer journey map, a service design tool, which de-
tails the customer experience in a value stream format. It pinpoints needed
service delivery roles (and supporting systems) and their information
touchpoints and again enhances focus on the customer and user experi-
ence.

CLC and Channels

Customer life cycles can be, and are often, further divided into
(communication) channels, e.g. retail store, web shop etc. Again, depending
on where your product is in its life cycle the main focus of your upcoming
product effort might very well be more customer life cycle related rather
than purely product related. It is important to keep a customer-centric view
because the customer does not differentiate between the actual product
capabilities and the supporting processes.

Customer journey
A customer life cycle describes high-level customer interaction, while a
customer journey portrays the complete customer experience by visualizing
every touch point with a product (or service). Use customer journey
mapping to identify capabilities (and conditions and constraints) at each
touch point. If the customer life cycle has been divided into channels, one
customer journey map per channel (or color coded stickers) is required.

The touch points are the tangibles that make up the total experience of
using a product (or service). Touch points can take many forms, from
advertising to personal cards, web- mobile phone- and PC interfaces, bills,
retail shops, call centers and customer representatives.
28
 )o
>
eb
Use a customer journey
to visualize the complete
customer experience

A customer journey is basically a very high level, touch-point driven flow

chart showing the customer main steps and how it connects to manual
and/or digital process support in each main step (ie what devices are
involved). Again, context is key.

As a customer journey map visualizes the overall service, its a piece of

cake to capture high-level product capabilities that we can write up as
user stories. These high-level stories become story map backbone before
they are decomposed to appropriate level of detail. One tip to get total
overview is to build these models on the same wall, the user story below
the customer journey map. At this point you may have spent 2 days in total
on building the BMC and capturing product capabilities ie user stories by
creating a Customer Journey. Lets take the final step in this loop which is to
build the high level backbone release plan.

THE RELEASE PLAN

Now we, in the development team, have everything we need to collabora-
tively build our Release plan. This is the last step in the loop and now we
look into and give initial time and costs estimates for the upcoming product
efforts being planned (ie release/releases). We recommend User Story
Mapping as a great way to visualise the work needed as well as identifying
your release strategy.

User Story Mapping

Arrange your capabilities ie your epics and decomposed user stories into a
structured model to visualize the product backlog as the total use of your
product including each actors usage perspective.

Epics are arranged from left to right in time sequence order. Each epics
break down into several smaller user stories. A high position indicates they
are absolutely necessary, lower position indicate they are of less business
importance.

29
User Story Decomposition
The user story map format will support the need for story decomposition
since the epics of the backbone (the user activities) are directly related to
their smaller stories under them (the user tasks needed to succeed with
the activity). They must to be decomposed into several sub-stories, i.e. ad-
ditional user stories of greater detail and doing this while building the user
story map fits well because it gives the stories context and also provides
prioritization of the user stories. All stories must also have an estimation,
preferrably using relative estimating techniques such as ideal engineering
time or story points.

Please note that story decomposition is an ongoing activity in agile

product development. A rule of thumb is to stay one iteration ahead of the
implementation iteration. Right now we are creating output needed for an
upcoming release plan, when the release have started we apply the rolling
wave principle of one iteration ahead (so called product backlog refinement
or grooming the backlog).

Now we have a larger set of contextualised capabilities from a user

perspective that we can trace directly back to the high level capabilities
needed to support the business model canvas we are trying to achieve.

RELEASE PLANNING
The users stories placed high on the story map describe the smallest
product (or service) that would give end-to-end functionality and deliver
the business value declared by a release goal. This functionality should be
released first, before anything else is worked on. Draw a line across the
user story map to visualize the user stories of product version 1.

A Release Plan specifies the capabilities ie user stories of each product

version and date for release. This time plan or look ahead plan is suitable
for mapping in long lead time items such as purchases of equipment and
external deliveries into the project in parallel with the planned iterations
in the release/releases. It is also a useful visual to use with business
stakeholders that are used to the more Gatt-like view of projects.

Please note that we are not promoting a big plan up front with a full
breakdown up front of all product capabilities/user stories. A release plan
has more decomposed iteration candidates for the first iteration, the rest
of the release candidates stay on a higher level of detail and we use rolling
wave planning while working on one iteration to prepare and decompose
upcoming iteration candidates during the release as work progress.

30
Split initial product version into iterations and derive duration
A pre-requisite for release planning is the expected velocity at which user
stories are implemented and the iteration length. It is also common to set a
iteration cost (based on # of individuals in the team and their allocation)

Velocity = story points/iteration (25).

Iteration length (4 weeks)
Iteration cost (10000 $)

Summarize the total number of story points for release of product version 1
(75) and split it into iterations based upon the velocity (75/25 = 3).

Release of product version 1 will be delivered in 3 iterations

Release of product version 1 will cost 30000 $

Derive duration by calculating number of iterations x iteration length

(3x4 =12 weeks).

Release of product version 1 will be delivered in 12 weeks.

Revisit the user story model after every iteration

As user story effort (story points) is estimated and velocity (story points/
iteration) is guesstimated, initial release plans will be revisited and
adjusted in accordance with the real measured velocity once iteration
execution starts.

The user story map can be used as-is, but it is commonly split into product
backlog, release plan and iteration plan for practical reasons, such as,
version control, information sharing and storage. The release plan can be
used during demo/review events as well as iteration planning events to
keep focus on coordinating a cadence between the development team work
(iterations) and the delivery organisation and their deliverables.

Congrats, you have concluded loop 2, you have now a Business model
canvas aligned with a User story map and a high level look ahead plan the
Release plan. These outputs will support the ongoing strategic decision-
making around your development efforts as well as helping the team keep
focus on more long term value delivery than just the next iteration.

31
 p
r
o
t

t
p a cn g
i mp p i
ma

LOOP 2:
GO & DO!
FOR an organization delivering products through a simple
customer lifecycle, WHO HAS a need for a product visualization/
prototype before proceeding with project chartering and release
planning, Go & Do! IS AN agile collaboration loop, THAT delivers
a validated business model, UNLIKE a traditional business
initiative, GO & DO! delivers in 5 working days

This loop generate prototype(s) to get customer insight and hence to

validate business viability. Loop 3 is suitable for teams and organisations
want to explore customer and user preferences and needs through
validated learning in order to really understand what do the right thing
right and fast means for their customer base.

A pre-condition to succeed with the loop is to execute the techniques with a

collocated, cross-functional team with demo and/or deployment access and
with key stakeholders and customers available in parallel for fast answers
and validation of results.

When to use
Loop 3 is used when the answer is yes to any of these questions:

Is your product context such that you can deploy prototypes for actual
customer and user feedback (validated learning)?
Do you need a validation of what business value strategy fits your users
and customers?
Do you need to start aligning the ongoing output from you agile
development with an evolving business model then this loop might fit
your needs.

32
 ub siness mod
t el
o c
y
p

a
i

n
n

va
g

s
go
&d
o!

Time box
5 working days

Lets get into the loop

No time for analysis paralysis just do it. Why should we deliver this prod-
uct? Who are the stakeholders? Which are the most critical impacts/capa-
bilities that our users and customers really need? This loop is inspired
by Lean Startup principles such as minimal viable product and validated
learning. Lean Startup is a concept created by Eric Ries and it is based on
a Build-Measure-Learn cycle of continuous innovation that is at the heart of
loop 3. You can read more about Lean Startup here:
http://theleanstartup.com/#principles.

33
 Impact Mapping
Impact mapping is a technique that fits well with aspects of Lean Start up,
we recommend to start loop 3 with an Impact Map here is why!

Mind mapping is a suitable technique to boost creativity and help you to

find out, and also to remember why, through a connected visualization.
A good practice is to build mind maps and impact maps with stickers on a
white board. This format lets everyone in a team participate and it is easy to

dy, go!
make changes.

Impact mapping was created by Gojko Adzic as a means to shift the

conversation from what is needed to why we want to achieve a certain type
of business goal or effect and identifying the impact needed in order to
reach the goal. The model is about understanding the behaviors that need
to change among key stakeholders in order to achieve a sustainable result.

What?
How?
What?
Who?
How? What?

What?
Why?

What?
How? What?

Pro
Who?
How? What?

What?

ac vis d
y
As such an Impact map is a specific mind map format, which organizes
your ideas in a logical structure deriving the minimal amount of

pp
capabilities (what) needed tied together with strategies on how to facilitate

io
the changed behavior (how) among key stakeholders (who) that need to be
impacted in order to achieve the goal (why).

in
First, identify the goal, why is this important?
Next step, who are the stakeholders/actors who we need to influence
and impact (who can block it or support the goal)?

34
 What are the actual impacts we need the actors to engage in as a
desired change of behaviour in order to progress towards the goal?
Finally, what organizational activities and/or software capabilities, in
short the deliverables that will facilitate the impacts being achieved?
At this point you can focus on finding the shortest path through the
map in order to execute the goal. Applying this strategy gives you the
least wasteful first view of work needed!

Impact mapping may look straightforward but an experienced facilitator

will certainly be worth the effort.

We think Impact Mapping is a good way to initiate the Inception work since
it is a fast, structured way to identify the game play, the value strategy, that
we need to agree on before we start to work more product and capability-
centric and build the prototype.

After a quick brainstorm, to find out why, for whom, how and what, it is
time for UX. You might think this is for specialist only. Well, it used to be,
nowadays there are pretty cool tools at hand, but a Lean UX specialist is
always handy.

Prototyping
Transform the identified product capabilities into a prototype; visualization
is a superior means of communication, to get early customer insight.

Start by making the simplest possible prototype, a minimal viable product,

as its whole purpose is to validate the business model through customer
feedback, typically people start sketchy and improve look and feel as an
idea evolve.

In order to use your prototype to generate insights you must decide on

target customer segment. The quickest possible way to identify customer
segments in relation to value proposition, revenue and cost structures, is to
play with a business model.

35
Business Model Canvas
A business model canvas explores the viability for a product idea,
commonly by smoke testing prototypes, e.g. landing pages against
identified customer segments. The main purpose is to create a valid
business model or else to kill early.

Key Key Value Customer Customer

Partners Activities Propositions Relationships Segments

Key Channels
Resources

If yours is a product effort from scratch this we recommend that you and
your team build a Business Model Canvas in order to have a structured way
to perform your continuous innovation of the minimal viable product (MVP)
or prototype. And even if you are working on planning the next larger step in
your Product Lifecycle of an existing product it might be beneficial to try out
this technique in order to really narrow down the most critical steps needed
to achieve a tangible business result.

The Impact map that initiated this loop help creating crucial output that the
Business Model Canvas template use as input to integrate and construct
an initial BMC. Actors supports the Customer Segments as well as Key
Partners part of the BMC. Impacts and deliverables supports the Value
Proposition as well as Key Activities.

After populating this information it is time to start thinking about cost

structure and revenue streams. Then design a hypothesis and formulate a
quantifiable metric. Finally create a prototype and generate insights from
your customer segment. We view the BMC as a the main technique to make
your Impact map come alive and to support the validated learning and
continuous innovation work that is at the heart of this loop.

We would like to expand on the aspect of the hypothesis in order to make it

easier to understand how done the prototype or minimal viable product
(MVP) can be to yield useful input from the customers. The hypothesis in

36
this case is a test hypothesis that needs formulated, quantifiable metrics
that supports the insight collection.

Some popular test strategies are summarized below:

Smoke test (complete product)

The MVP strategy for a web application (or app) is to create a mock
website (or app) for the product and purchase online advertising to
direct traffic to the site.
The mock website (or app) may consist of a marketing landing page
with a link for more information or purchase.
The link is not connected to a purchasing system, instead clicks are
recorded and measure customer interest.

Deploy first, code later (feature by feature)

A link to a new feature in a web application may be provided in a
prominent location on an existing website.
The feature is not implemented, rather an apology, mock-up, or
marketing page is provided.
Clicks of the link are recorded and provide an indication as to the
demand for the feature in the customer base.

Concierge
Manually perform the service you want to investigate, for a customer
in your customer segments for free, for a period of time.

Wizard of Oz
People doing manually work behind the scenes

Build an audience
to reconcile your thoughts
to have potential customers when the product is launched

Crowdfunding
Sell the product to people before you have the product
Ask for a credit card or pre-payment

Collect metrics, adjust the prototype and generate new learnings rinse
and repeat!

Congrats, you have concluded loop 3 or more correctly started loop 3. You
have now a Business model that is validated while incrementally exploring
the prototype with actual customer input, minimizing waste and maximiz-
ing value delivery. The Impact map supported the kick start of crucial input
data for the BMC as well as helping to identify what the MVP needs to
contain a very useful means to an end.

37
FURTHER READING &
ACKNOWLEDGEMENTS
We hope you have enjoyed reading about our 2 cents on how to combine
different agile inception techniques. Remember, the loop approach of three
main agile inception strategies that we play with in this book are three out
of many. You will pick and choose and put together the loop you need, we
wish you the best of luck!

If you are interested in more hands-on support on how to execute the

techniques in the loops we are updating the blog ongoing with our
workshop materials free of use. Hopefully these workshop designs will
make it easier for you to get started!

And a final note, if you thought we were a bit skimpy on the details regard-
ing user story format, writing, modeling and agile requirements in general
then you are correct. Those details are so important and crucial that they
deserve their own in 60 minutes! Keep a look out on the blog for the
upcoming Agile Requirements in 60 minutes, we aim for autumn of 2014
release of the next book.

Thank yous and salutations

Firstly, we would like to thank Softhouse Consulting AB and the Scalare
EU-project for letting us spend work time on this instead of our evenings
and weekends which we initially had planned to do. (our families are
grateful too!)

Secondly, our saluations go out to the following people who have

inspired us:
James Shore and Diana Larsen
Henrik Kniberg
Gojko Adzic
Jeff Patton
Alistair Cockburn
Thiagi
Eric Ries
Roman Pichler
Always: Fred Brooks and Gerald Weinberg
and many more

Copyright
We hope you find the information in this book useful. If you wish to use
content or use images that are part of this book, please acknowledge the
source when doing so. Copyright Softhouse Consulting AB.

38
What is a in 60 minutes?
We are inspired by Open Source communities where principles of open
and free access to knowledge and results is central, information as well as
experiences needs to be shared. The agile community is very much driven
by contributing and sharing knowledge and we have benefited much from
others work, it is about time we contribute as well.

When talking & conceptualizing the in 60 minutes and the related

2cents on Agile blog idea we specifically used Scrum and XP from the
trenches by Henrik Kniberg as an example of the type of hands-on pub-
lication we wanted to create although you will see how in 60 minutes
differs due to the nature of content and areas we adress.

The publication Agile Inception in 60 minutes is accessible on the Lean

Magazine web page. The magazine has quite a good spread in Sweden and
the articles are high-quality, touching on various different agile related
subjects. The magazine as well as the web page is sponsored by Soft-
house and being an english speaking web page we felt it was the natural
starting place to host the 2 cents. on Agile blog and its related pupli-
cations, the first outbeing Agile Inception in 60 minutes. Please visit
www.leanmagazine.net for more information.

39
ABOUT THE AUTHORS
Bea Dring and Hkan Kleijn are Agile coaches
working for Softhouse Consulting AB in Sweden.

Bea is a high school teacher who accidentally

dropped into the IT-business. As a consultant
manager she read eXtreme Programming ex-
plained, got hooked and became an evangelist of
XP-techniques. She has been coaching large and
small scale agile adoption with focus on change
management and Agile requirements.

Hkan, MSc in chemistry, started a career

focused on quality in the pharma industry.
Beginning with ISO, he has fallen for every hype
ever since: CMMI, RUP, UML, ITIL, Lean software
development, Six Sigma, eXtreme Programming, Softhouse Consulting
Scrum and Kanban. He has been coaching small
scale and company wide agile adoptions, as Stockholm
well as being globally responsible for software Tegnrgatan 37
SE-111 61 Stockholm
configuration management.
Tel: +46 8 410 929 50
info.stockholm@softhouse.se
Please visit us at:
Gteborg
http://en.softhouse.se/info Lilla Bommen 1
SE-411 04 Gteborg
http://softhouseeducation.se/shop Tel: +46 31 760 99 00
info.goteborg@softhouse.se
Twitter: @2bea73 Malm
Stormgatan 14
SE-211 20 Malm
beatric.during@softhouse.se Tel: +46 40 664 39 00
hakan.kleijn@softhouse.se info.malmo@softhouse.se

Karlskrona
Campus Grsvik 3A
SE-371 75 Karlskrona
Tel: +46 455 61 87 00
info.karlskrona@softhouse.se

www.softhouse.se