Agile Inception in 60 minutes

AGILE INCEPTION Bea Düring & Håkan Kleijn

– The Loop Approach ry tiety r s a l o

Mquearat n

ge

Pu

fo

rp

bu

os e

cu s

il

de

r

BRAINPOWER

to tYour he tri cusultimp exp tome ate erie r nce

Aut cre on ativ o ity my boo s

ter

to tYour he trip cusultim exp tome ate erie r nce

BRAINPOWER

Aut cre on ativ o ity my boo s

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 experiences 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

ter

Pu

fo

rp

bu

os e

cu s

il

de

r

ry e 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 beatric.during@softhouse.se

H책kan hakan.kleijn@softhouse.se

Web: http://en.softhouse.se/info

http://softhouseeducation.se/shop Twitter: @bea73 3

INTRODUCING THE LOOP APPROACH

!

O G

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 complicated 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 management/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 down to this:

o!

o!

GO!

Go & D TEADY S Y D EA

R

GO!

Loop 1: Ready, steady, go!

Purpose and fit: This loop use collaborative agile techniques to generate a similar outcome as a traditional feasibility or prestudy. The time box of 5–10 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!

4

Go & D

Go & Do!

Loop 2: Go!

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 crossfunctional workshops to produce critical business 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 organisation 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 contextualizing the ideas in this publication to fit your organisation and your needs.

This book doesn’t 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 effort. 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 generating prototype(s) to get customer insight and hence to validate business viability.The time box of 5 days consists of a series of accelerated 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, d a y, e R ad e StGo! OP

1

LO

I

MPACT M

vis i

on

ING! APP

Pr

od uc t

Bu m sin o ca de nv a

PR

OD

UC

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 business model and a story map, UNLIKE a traditional feasibility study, “READY, STEADY, GO” delivers in 5–10 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

ycle

eC r Lif

e

tom Cus

me

to Cus

ney

ur r Jo

ne el ss as

ing

ann

e pl

eas

Rel

M AP

• 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 5–10 working days.

Let’s 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.

Who?

How? How?

What?

What?

What?

What?

Why? Who?

How? How?

What?

What?

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 capabilitycentric. Let’s not forget though that already at this stage you will have homed in on the high-level capability areas that will drive your impact, we’re 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 vision activities. Let’s look at our favorites.

9

10-15 subfeatures on back

M

A R

K

E T

Pr naoduc me t 1: 2: 3:

Product Box Imagine your product is offered to the market in a box. How would you design it?

Sidebars

Cover Story

Quotes

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, techniques like dot-voting and fist of five polling is used to encourage participation, contribution and to achieve consensus.

Elevator Pitch sentence structure: FOR

(target customer)

(customer need)

IS A

,

, WHO HAS

(product name)

(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 coordination 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.

Xxxx

MOI?

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 description of a fictional person’s 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’ characteristics, demographics and goals, to zoom in on your customer segments.

12

13

good to produce 2–4 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 attributes 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 capabilities will appear in the overall customer experience. A Customer Life Cycle model also facilitates value prioritization when having to make tradeoff 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 colourcoded 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-beforedepth meaning horizontal coverage rather than vertical depth of details.

Let’s 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 (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.

15

eb

>

)o

Use a customer journey to visualize the complete customer experience

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 3–4 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 it’s 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 View Products Purchase Products Online Customer

Manage Customer information

Compare Products Manage Product

Marketing Administrator

Report Product Sales

Payment Processing System

Fulfil Order

Report inventory Manage inventory

Warehouse Clerk

Warehouse 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 capability (ie feature possibly written in user story format) can co-exist with other capabilities to achieve a goal. What’s not to like with it?

What are Use case diagrams? Use case diagrams provide a simplified and graphical representation of an actor’s 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 describes 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 Partners

Key Activities

Key Resources

Value Propositions

Customer Relationships

Customer Segments

Channels

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.

Goal

Feature Metric

Acquisition: Free app, limited inapp purchases

Activation: Focus on in-app purchases

Retention

Acquisition New segment

• Basic functionality

• Purchase new outfit

• Additional skill levels

•New characters

Downloads: top 10 game app

Activations, downloads

Daily active players

Downloads

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 collaboratively 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 Role 1

User Role 2

User 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 1(5) Story 4(8) Story 7(3)

22

Story 20(2)

R1

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

Story 18(5)

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

cu

u s U jo t s d e o u e r m r c n e s o e r m to y p r o y s it io n

st om er li fe cy 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

bu

si

ne

ss

mo

de

l

eg sn a i e n l n ea Rl p

c

v an

as

2 p o Lo ! o G

Time box 3 working days.

Let’s 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 Partners

Key Activities

Key Resources

Value Propositions

Customer Relationships

Customer Segments

Channels

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 understanding 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 usercentric 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 colourcoded 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?

Let’s bring on the customer journey map, a service design tool, which details 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 experience.

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, it’s 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 collaboratively 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. additional 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 decisionmaking 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

t a cn g p 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

r

o

t

t

ub siness mod o

y

va

n

n

i

c a

p

el

g

s

go

&d

o!

Time box 5 working days Let’s get into the loop No time for analysis paralysis – just do it. Why should we deliver this product? Who are the stakeholders? Which are the most critical impacts/capabilities 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 make changes.

dy, go!

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.

Who?

How? How?

What?

What?

What?

Why? Who?

ac y pp in

What?

How? How?

What?

What?

Pro d vis io 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)?

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 capabilitycentric 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 Partners

Key Activities

Key Resources

Value Propositions

Customer Relationships

Customer Segments

Channels

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 maximizing 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 regarding 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 “2 cents 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 publication 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 Softhouse 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 puplications, the first outbeing “Agile Inception in 60 minutes”. Please visit www.leanmagazine.net for more information.

39

ABOUT THE AUTHORS

Bea Düring and Håkan 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 explained, 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.

Håkan, 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, Scrum and Kanban. He has been coaching small scale and company wide agile adoptions, as well as being globally responsible for software configuration management.

Please visit us at: http://en.softhouse.se/info http://softhouseeducation.se/shop Twitter: @2bea73 beatric.during@softhouse.se hakan.kleijn@softhouse.se

Softhouse Consulting Stockholm Tegnérgatan 37 SE-111 61 Stockholm Tel: +46 8 410 929 50 info.stockholm@softhouse.se Göteborg Lilla Bommen 1 SE-411 04 Göteborg Tel: +46 31 760 99 00 info.goteborg@softhouse.se Malmö Stormgatan 14 SE-211 20 Malmö Tel: +46 40 664 39 00 info.malmo@softhouse.se Karlskrona Campus Gräsvik 3A SE-371 75 Karlskrona Tel: +46 455 61 87 00 info.karlskrona@softhouse.se

www.softhouse.se