The Agile Setup: How Marmelab Bootstraps Projects In 2 Weeks

At Marmelab, we've discovered that one of the keys to success in innovation is to start soon. There will always be a lot of uncertainties ; the best way to lift them is to produce a minimal product, put it in the hands of the end users, and observe.

Our customers usually give us a very brief expression of their need. To go from this description to writing the first line of code, we limit ourselves to a two weeks period, which we call the Setup Sprint. We use this time to build artefacts which are essential to knowing the end user, understanding the problem, and designing the solution - in collaboration with the customer.

• Objectives
• KPI
• Risks
• Competition
• Personas
• Ubiquituous Language
• User Journeys
• Technical Architecture
• User Stories
• Product Backlog
• Estimates
• Sprint Backlog
• Roles and responsibilities

In order to illustrate all of these artefacts, I will use, as an example all along this article, a real project called TobaccoBot - a virtual coach to help people quit smoking via Text messages.

Definition Of The Objectives

To make sure we are aligned with what the customer wants us to do, we have to clarify their objectives.

That's why we work with our customers to write their project vision, using the "elevator pitch" template:

For [the product’s target market]

Who [statement of the need],

The [Product name] is a [Product category]

That [key benefit].

Unlike [competitors/current situation]

Our product [statement of primary differentiation].

As an example, here is the vision of our project "TobaccoBot".

For the smokers Who are willing to quit smoking, Tobaccobot is a personal coach That, based on Behavioral psychology, allows to quit smoking in 4 weeks. Unlike sixty-something Androïd applications on this topic, Our service works without any interface, that is what prevents us to join dozens of unused apps in the phone of our users.

We also use a Business Model Canvas in order to set a clear context for the project we are about to work on.

This tool, used to describe a business idea in a synthetic way, is very useful to test the maturity of the customer's project.

Very didactic, the 9 blocks are also a good guide to bridge the gap if necessary. We are generally using it to challenge our customers on their strategic choices, when the time comes to prioritize what has to be developped first...

Here is the Business Model Canvas for Tobaccobot. It is not very detailed as it is just an experimentation we will not turn into a business. But it is detailed enough to show you what the exercise looks like.

KPI Definition

During the second step, we focus on identifying measurable criteria, also called Key Performance Indicators (KPI). The KPI will allow us to determine whether or not we progress in the right direction.

Determining those indicators at the very begining of the project enforces our customers to focus on tangible elements. This exercise is not easy at all - it is much easier to fall into vanity metrics.

At this stage, we try to define between two and five indicators, and a target value for these indicators at the end of the initial experimental period. These indicators must be measurable as soon as the first iterations end. This implies early prioritization of measurement tools.

For TobaccoBot, we want to validate that we can maintain contact with users over time, through a conversational bot. We also want to validate that our bot is effective at getting people to stop smoking. Our indicators are:

• 50% engagement: At the end of a 4-weeks coaching, we want to reach a rate of 50% of users who finished the program.
• 50% success: For those 50% who finished the program, we want to reach a rate of people who actually quit smoking of 50%.

Even if these KPIs are relevant, they have the disadvantage of being difficult to measure (since the coaching program takes 4 weeks). In this case, intermediate objectives should be defined, such as:

• 90% early engagement: 5 days after subscription, 90% of the users must have answered to the morning text message within a day.

Risks Identification

In the context of innovation projects, where the level of uncertainty is high, it is important to identify the risks because they are a good prioritization tool. Indeed, if we have to fail, let's fail as soon as possible. We will therefore try to remove the most important risks as soon as possible. So, if one of them is insurmountable, we will have spent limited time and resources when we discover it.

The risks can be related to various topics:

• technical risks, such as a security vulnerability,
• functional risks, such as a feature that doesn't serve its purpose for the end user in practice,
• market risks, such as having to coordinate the release of the product with an outside event, such as a trade show

We then integrate those risks in our strategy, whether on planning, on technical design, or on the validation of hypotheses.

Here are the risks we have identified for TobaccoBot:

• a technological risk, because the technology behind the bots is far from mature (especially on the natural language processing). We see a lot of half-finished libraries circulating, and some free solutions today may not be available tomorrow.
• a functional risk, as we do not know if this method actually works to stop smoking.
• an economical risk, since the sending of text messages is not cheap, which makes it very dangerous to use a "freemium" economic model.

Strengths And Weaknesses Regarding The Competition

If the product has no competition, it's usually a bad sign - a problem not worth solving. In most cases, alternative solutions already exist, and identifying their strengths and weaknesses allows us to understand the key differentiators for the end users.

What we learn from the competitive analysis are the aspects of the domain that competitors have addressed, their positioning, but also the user experience they have set up. All these elements allow our customers to better position them - and our customer - in their market.

From a methodological point of view, here is how we realize our benchmarking:

1. We define criteria for comparison,
2. We test each of the competing services according to these criteria,
3. We collect all the answers and try to identify clusters,
4. We reduce the number of criteria to the two most significant (or discriminant)
5. We place each competitor on a two dimension chart

For Tobaccobot, there are at least 60 competing products - all using a mobile application. We decide to give the same service via Text message, meaning it's a "no interface" application. It gives the product four advantages over the competition:

• reduce friction during installation (since there is no installation)
• make recurrent use easier (no need to look for the app among many other installed apps)
• reduce cost by skipping the work to address many app stores
• works on feature phones, too!

Here are the applications that have the best notes on the Play Store.

Most of them underline the potential savings in cigarette consumption as the main motivation. Some also sell and increased life expectancy. We also believe think that the initial motivation is key to quitting smoking, but not enough to follow a program over several weeks. So we decide to focus on engagement over the long term as a main differentiator from competitors.

Here is the final competitive chart.

Designing Personas

Marketing people, UX designers, and also computer scientists use the technique of personas. It involves creating portraits describing typical users. This allows us to "personify" the different categories of end users who will use the application.

This approach force our customers to think again about who their services are made for. Customer segmentation has already been done at the Business Model Canvas stage, but the idea here is to transform a segment into a person - an additional step in the process of mastering the subject.

As communication people say, "When you talk to everyone, you do not talk to anyone". Knowing your users is essential: it empowers you to provide a useful service, and to segment your market accordingly.

An important point is to clarify the objectives of each persona, the tasks he or she wants to accomplish, and that our solution should facilitate.

The technique of the personas is key to allow a user-centric approach. On this same blog, you can find an article that we had dedicated to the personas technique.

Here are the personas we chose to consider for TobaccoBot:

Brice Brice is a smoker. He wants to quit smoking. It is not the first time he tries to: he already experienced patches and acupuncture, without any success. He is around forty years old, and has a kid. He realizes that if smoking was cool when he was younger, it is much less so today: looking at his daughter, he thinks he does not want to leave too soon. What makes him smoke again: his stressful work (he is a commercial), and the fact that he likes to go out and drink with friends. He spends about 40€ a week on cigarettes, which is a lot for his budget. His phone, a 3 year old Huawei, is full of applications he never uses. What he is looking for: motivation when he needs it. Since he does not want to leave anything to chance, he wants to be accompanied by a professional. He never used our tool.

Thomas Thomas is customer relationship manager at TobaccoBot. Comfortable with computers, he works at the office on a last gen PC with a wide screen. He focuses on maximising the AARRR, the famous five axes of growth hacking (Acquisition, Activation, Retention, Revenue, Referral), that is why he needs data on customers activity so that he can analyze why some customers choose to leave the program. Thomas never hesitates to pick up his phone.

Definition Of The Ubiquituous Language

In order to further deepen our knowledge of our customers' business domain, we write down the vocabulary that we are going to use during the project. We define this vocabulary in the most precise way possible, taking care of removing all language ambiguities before misunderstandings arise. We call it the ubiquituous language, a term borrowed from Domain Driven Design (DDD).

The terms we describe in this list are in English, even if our customers and our developers are not native English speakers. Because the code is in English, having a common language based on English words allows to use exactly the same term at all stages. This also avoids interpretations during translation that the developer should inevitably do.

For TobaccoBot, here are the terms of the domain we have listed:

• Subscription: In order to participate in the program and receive text messages, the user has to enroll in the program. This event is called a subscription.
• Goal: The objectives of the program are personalized for each user. They are determined based on the number of cigarettes smoked daily when they start the program. so each user has a personal goal.
• Daily target: Calculated from the goal, the daily target varies along the program. for instance, for a smoker with a 20 cigarettes per day consumption at the start of the program, the daily target will be 15 cigarettes per day the first week, then 10 cigarettes per day the the second week, etc.
• Question: The message sent everyday to the end user, asking them the number of cigarettes smoken the day before.
• Consumption: The number of cigarettes smoken the day before by the user, sent as a response to the questino, and compared to the daily target to determine if the user is heading in the right direction or not.
• Advice: The message generated by the bot, and sent daily to the end user as an answer to the consumption response.

User Journeys

At this stage, we design the different steps the user will follow to achieve their tasks. This helps our customers to visually go further in the description of their expectations.

Note that it is the first time in the process that we talk about the solution, since all the previous steps were focusing on the needs. Working on the user journey usually represents most of the time spent during project setup. The result is usually a gathering of drawings of all types.

Once we have visually defined one or more journeys as a map, we ask our customers to identify one minimal path in tha map that brings the core value to their end users. This will be very useful during prioritization.

For TobaccoBot, here is how we initially designed the user journey.

As a result, here is the detailed conversation workflow we ended up with:

Technical Architecture Design

Parallel to the functional solution, we work on a technical solution.

This step is the opportunity for us to discover the technical constraints of our customers, and to adapt our design to them, or to propose new solutions.

We put our expertise and experience to design and propose a set of tools and components that fit the customer's requirements - not the latest trends in Hacker News. The outcome of this discussion is an architecture diagram, listing the languages and the tools that we will use for each component.

Most of the architectures we deliver today are API-centric, and contain at least two applications: a frontend application (web or mobile), and an administration application.

For TobaccoBot, it is almost like this, but there are two frontend applications: a web app to enroll in the program, and a text messaging app for the daily interactions.

User Stories

Based on the user journeys, we split the features of the solution into simple units of work that a developer can understand. It's a way to "translate" customer requirements to an agile format.

We mostly follow the Scrum rituals and formats: two-weeks sprints, a team composed of two developers and a facilitator, daily stand-ups, retrospective, sprint planning, and a continuous improvement process (for further details, please take a look at our article (in french) about the agile iteration). In Scrum, features are written in a user-centric, informal description called user stories.

Here is the format of a typical user story:

As a [persona]

I want [action to perform]

So that [expected benefit]

We usually add some acceptance criteria. Those acceptance criteria complete the requirements, as they provide validation conditions for the solution.

Our acceptance criteria usually follow the following format:

Given [the state of the system],

When [I perform this action]

Then [I obtain this result]

User stories are written based on personas, the user journey and the ubiquituous language.

As it is raw material for the developers, and because they will have to use them to write code, user stories and acceptance criteria are written in English.

Here is a sample user story for our project TobaccoBot:

As Brice I want to answer to the bot about the number of cigarettes I have smoken yesterday So that I can receive stimulations in return and keep motivated

And then, an example of an acceptance criteria related to this user story:

Given I subscribed to the program When I send an SMS to answer to the message of the bot with a number inside, written in letters or numbers, with or without additional words Then the Bot takes into account this number as the number of cigarettes I have smoken yesterday

Product Backlog And Story Mapping

User stories are gathered in a product backlog. As we usually work remotely with the Product Owner, the backlog is shared on the Internet. We use Trello for that.

Once written, user stories must then be prioritized in terms of user benefit. The technique called story mapping usually facilitates this work: indeed, starting from the map of the user journey, we are able to determine whether a feature is necessary or not, and then design a first coherent functional set.

Estimates

Now that the solution is described (user journey) and split into atomic features (user stories), it's time to estimate the complexity of each feature. This complexity is usually a good sign of the cost to develop the feature.

We let the developers estimate the complexity of each user story, because they know best. They estimate it collaboratively, using the Planning Poker technique. All developers receive a set of cards that facilitate the conversation during the estimation. This allows to estimate a lot more user stories than with classical estimation techniques.

Estimations are in man.days for each user story. It remains a raw estimation, just an idea of the amount of work to be done: values used in the planning poker are 0,5 days, 1, 2, 3, 5 days. This topic is controversial: actually, most of the Scrum teams try to avoid man.days to quantify the work to be done. We still use man.days because, in our context of projects that last only a few sprints, projects do not last long enough to stabilize the estimation in velocity per story points. According to our context, it is the best compromise.

A Planning Poker session is long and tiring, because you need at least 3 hours to estimate enough user stories to fulfill one iteration (20 man days of development). Why is it so long? Because during the planning poker, we talk about implementation scenarios, we discuss with the product owner the best cost/benefits ratio.

We usually do not estimate the entire product backlog - only the part of the backlog the product owner selects as the one bringing the more value and/or clarifies the most our uncertainties. Another good reason to not estimate the whole backlog is that a user story must be detailed enough to be estimated, and this needs a lot of preparation by the Product owner. If we had to wait for the whole product backlog to be ready before starting estimating it, then the preparation phase would last months and not two weeks.

Estimates let the Product Owner prioritize the backlog again by crossing the priorities of the business and the complexity of each feature.

Sprint Backlog

Once the estimation of the most important part of the product backlog is done, the product owner takes the user stories at the top of the Product Backlog, and use them to fill a second queue, the Sprint Backlog. The sprint backlog as a limited capacity - the number of man.days of an agile iteration (2 weeks by 2 developers = 20 days, minus 2 days for the agile rituals, 18 days). The Product owner stops filling the Sprint Backlog when the sum of the complexities of the user stories reaches the sprint capacity.

The Product Owner will repeat this exercise every to weeks, in order to plan the following iteration.

Document Project Organization And Schedule Meetings

On the web portal of the project (we generally use Basecamp), we list some information related to the project organization:

• roles and responsibilities
• contact datas from the customer and from Marmelab
• the list of tools used, with hyperlinks and access codes

We also schedule with our customer the next meetings related to the project, such as Planning meetings, Review meetings and retrospectives for the next few sprints.

Conclusion

Two weeks may seem like a lot, but it is very short to gather all the information and produce all the documents listed in this post. It is also an necessary step for every project: these two weeks days mark the beginning of a collaboration, a true foundation on which the product that we are going to develop can rise.

During this period, we sometimes perform agile coaching, or rather training on how it all works, on who does what, all illustrated by our past experiences. There is no deliverable for this, but it is part of our contribution to the project.

Finally, even if we rarely do it, we seek formal approval from the customer at the end of that period. If something goes wrong in the project, we prefer to realize it before writing the first line of code.

At the end of these five days, the development team is able to start writing the first line of code. But that's another story ...