Let’s dive into Agile Inception and HOW TO USE THE LOOP APPROACH! To start off, this is the first article of three explaining Agile Inception – The Loop Approach, and all three articles are part of Softhouse’s issue Agile Inception in 60 min. We hope you enjoy reading about how to combine different agile inception techniques. Remember, the loop approach of the three main agile inception strategies we use within this series of articles is three out of many. You will pick and choose and put together the loop you need. Enjoy the read, and best of luck with your loops!

By using a combination of techniques executed via a series of workshops, we can engage different groups of people in the organization 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 and scaled environments where multiple teams collaborate 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 organization and your needs. This article 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 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.

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 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 uses 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?
• Do you need to catch crucial upfront business data to facilitate a Go/No Go decision before entering release planning?
• Do you have executive decision-making stakeholders asking for pre-studies and heavier upfront requirement specs 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 we are 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 to get buy-in.

IMPACT MAPPING

Mind mapping is a suitable technique to boost creativity and help you to find out and also remember “why” through a connected visualization. A good practice is to build mind maps and impact maps with stickers on a whiteboard. This format lets everyone in a team participate, and it is easy to make changes. 

Gojko Adzic created impact mapping 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 identify the impact needed to reach the goal. The model is about understanding the behaviors that need to change among key stakeholders to achieve a sustainable result.

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 to be tied together with strategies on how to facilitate the changed behavior (how) among key stakeholders (who) that need to be impacted 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 actual impacts do we need the actors to engage in as a desired behavior change to progress towards the goal?
• Finally, what organizational activities and/or software capabilities, in short, are the deliverables that will facilitate the impacts being achieved?
• At this point, you can focus on finding the shortest path through the map to execute the goal.
• Applying this strategy gives you the least “wasteful” first view of the work needed!

Impact mapping may look straightforward, but an experienced facilitator will certainly be worth the effort.

Impact Mapping is a good way to initiate the Inception work since it is a fast, structured way to identify the gameplay and the value strategy that we need to agree on before we start to work more product and capability-centric. 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. 

Cover Story 

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

Typical for these vision activities is to time box them to half a day to build actual physical end results. 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 are used to encourage participation, contribution and to achieve consensus.

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.

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 discussing their different interpretations and end up with one clear agreement on what the product effort will offer and for whom. 

We now know why we must do what on a high level. Before we dive into the product capabilities in more detail, we focus on the target group and their needs by creating user personas, which facilitate a strong emphasis on the customer experience.

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 the planning of product capabilities and facilitate making trade-off decisions with user personas acting as the Voice of The Customer. It is good to produce 2–4 user personas 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 an 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).

It is time to take the ”what” and dive deeper into the capabilities needed to meet the product vision. We need to ensure we have “breadth-before-depth” on which part of the product and the product elements 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 needs 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 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. 

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 a way to model the capabilities and where they need to appear in the CLC model. In some teams, we use color-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 cover more than just product capabilities potentially. We are still focusing on breath-before-depth 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, webshop, 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). Touchpoints 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’s main steps and how it connect to manual and/or digital process support in each main step (i.e., 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 (i.e., features) and 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.

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 the context that will help us understand how a single smaller capability (i.e., a feature possibly written in user story format) can co-exist with other capabilities to achieve a goal. What’s not to like about 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 (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, the customer journey displays the information objects (touch points), while the use case diagram displays capabilities (features) and actors.

Identify actors, systems, 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 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; Verbs and Objects, 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 your Impact map and customer life cycle.

User Story Decomposition

These initial capabilities (written as user stories, i.e., epics at this stage) are too large to be implemented. They must 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, preferably 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 the output needed for an upcoming release plan; when the release has 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 organizations that need to do a bit more up-front detailing as part of planning the product effort, i.e., the release/releases. Use case diagram modeling is a fast, visual, and context-supporting technique. When doing the decomposition work, it helps the development to cognitively zoom in and zoom out when the volume of user stories increases.

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 with the actors and the users’ perspective. 

Business Model Canvas (BMC)

A business model canvas explores the viability of 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. 

A persona clarifies your customer segment. A product vision sharpens your value proposition. A customer life cycle/journey helps you understand 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 into 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 filling in the gaps.

If yours is a product effort from scratch, you and your team could 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 to really narrow down the most critical steps needed to achieve a tangible business result.

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 consider 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 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 organizations might need a more thorough understanding of the capabilities needed to be able to create a BMC and agree on it.

Now that we have integrated our business output and decomposed quite a 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 can make qualitative assumptions and not wild guesses about the planned product efforts ahead.

• 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 or 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 cost estimates for the upcoming product efforts being planned (i.e., release/releases). We recommend User Story Mapping as a great way to visualize the work needed and identify your release strategy.

User Story Mapping

Arrange your capabilities, i.e., your epics and decomposed user stories into a structured model to visualize the product backlog as the total use of your product, including each actor’s 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, and a lower position indicates 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, i.e., user stories of each product version and the 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 equipment purchases 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 upfront with a full breakdown upfront 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. 

Split the initial product version into iterations and derive the 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 an 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 the release of product version 1 (75) and split it into iterations based on 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 the number of iterations x iteration length (3×4 =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 the 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 now have 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 many capabilities that will enable their goals – and hence your impact and business goals.

Copyright

If you wish to use content or use images that are part of this book, please acknowledge the source when doing so. Copyright Softhouse NordicAB. We are inspired by Open Source communities where principles of open and free access to knowledge and results are central, and information, as well as experiences, need 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” differ due to the nature of content and areas we address.

Next article will be published next week!