Let’s dive into Agile Inception – The loop approach part 2! But first, this is the second 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! Read part 1 here!

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 organizations 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 needing new or enhanced services through an existing customer life cycle?
• Do you need a high-level look-ahead plan that covers multiple iterations of the release to coordinate your development efforts with a delivery organization?
• Do you need to enhance your agile planning game with a tighter connection to business value delivery then this loop might fit your needs.

Time box

3 working days.

Let’s get into the loop

It is easy to generate many 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 prepare for business model canvas, an ingenious one-page concept that will help you dig for gold.

Business model canvas (BMC)

Starting with the Business model canvas helps the team to focus on “doing 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 BMC 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. If yours is a product effort from scratch, we recommend 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 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 emphasize 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.

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. Please note that at this point in time, we have not spent time 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 do 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 a handy way forward and gives us a good basis for a more user-centric perspective during the planning work.

Customer Life Cycle (CLC)

When trawling for product capabilities during the inception work, we recommend using a Customer Life Cycle model to identify the high-level customer interactions 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 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.

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 value proposition to cover more than just product capabilities potentially. After some struggle, prioritization, voting, and decision-making, the business model is finally good enough and agreed upon. We do understand, on a high level, what capabilities our service must deliver 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 that 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). 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.

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 the story map backbone before decomposing to the appropriate level of detail. One tip to get a “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, i.e., user stories, by creating a Customer Journey. Let’s 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 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.

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; a Lower position indicates they are of less business importance.

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 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, 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”).

Now we have a larger set of contextualized 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 user 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. This “time plan” or look ahead plan is suitable for mapping 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 up front 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. The release plan can be used during demo/review events as well as iteration planning events to keep the focus on coordinating a cadence between the development team work (iterations) and the delivery organization and their deliverables.

Congrats, you have concluded loop 2!

You now have a BMC 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 help the team keep the focus on more long-term value delivery than just the next iteration.

The next (and last) article will be published next week!

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.