The module – in brief

The purpose of creating a process around developing your digital business model is to ensure that the model you end up with supports your business strategies and ensures that you can make optimal use of the business opportunities that lie in the digitisation of your existing business processes and in new digital processes. The development process must also ensure that your digital business model can be continuously developed and adapted so that your customers will always get the business experience you aim for, and so that you can always adapt yourself, your business model and your digital processes to the market in which you are operating.

Choice of development process

The development of concrete solutions – where you form the solutions – for a digital business model can be carried out in many ways. Which way you choose and which tools you use depend on many things:

• Digital solutions can be many things. Hence, what exactly needs to be developed?
• What resources are available?
• What experience do you have?
• How do you prefer to work?

There are many ways to go, but for the development of digital solutions – products, services, processes and so on – agile development has become very popular. The principle behind agile development focuses on rapid and continuous value creation as described in the module Basic Principles.

Agile development is a structured and iterative development process that in one go provides:

• Quickly implementable results,
• Opportunity for a high degree of ongoing user involvement, and
• Great flexibility concerning ongoing adaptation to changes, needs and requirements.

Thus, agile development can ensure that the result meets expectations. One of the key characteristics of agile development is that sub-results are continuously created, which can be implemented and which thereby generate value from the start. Hence, you do not have to wait to reap value until all sub-results have been gathered and the final goal has been reached.

Agile development does not have to be difficult: you can do it in small chunks. Start with one process, or just a part of one process, and think agile, make it agile, by using the tools and methods presented in this module. When one part works, you can continue with the next part – the next process – and so on.

The agile development process

For some companies, agile development will be a new way of thinking about development. The core principle in agile development is that the development process from start to finish is no longer one long and continuous process. When you do agile development, you divide the entire development process into short, structured “chunks”, which are called “sprints”.

Each sprint must contribute to the overall product with a new type of functionality that can be immediately implemented, tested, evaluated and launched – i.e. put into use! The agile development process is illustrated below.

“The agile development process” adopted from Digital Business Models for the Future under license CC BY-SA 4.0

In this way, you quickly achieve implementable results in the process, which can generate value, and gradually, the overall solution will take shape and will contain functionalities that are developed and that generate value along the way. Further, these functionalities can be adapted and optimised along the way because they are already being tested in practice.

“The waterfall process and the agile process” adopted from Digital Business Models for the Future under license CC BY-SA 4.0

Compared to the traditional, continuous development process, which is often called The waterfall process, and which only really creates value at its end, The agile process consists of a number of small and concentrated complete development processes, namely the individual sprints. Each sprint contains design, development, testing, review and launch of the result, and each sprint thus creates its own value. The total solution is the sum of all the tested and step-by-step results.

In this module, we recommend and describe two concrete tools for managing the agile development process called Agile Board and Scrum.

There are also several good tools for clarifying the expectations for the result – both the formal expectations and the expectations that may not have been put into words – and for making good and useful specifications for what needs to be developed. In this module, we recommend and describe the two tools called Use cases and User stories.

Agile tools

To control the overall process and to control the individual sprints and make sure that they are both agile and effective – i.e. that they can constantly be adapted to changes in reality when, for example, changes occur in specifications and goals, and at the same time progress effectively, a large number of different methods and tools exist. When such tools are used, they become an integral part of the agile process. Two examples of such methods are the Agile Board and Scrum.

The Agile Board

The Agile Board helps to maintain strict and constant prioritisation and management. Management of goods, tasks, production planning and so on. The method was originally called Kanban and originates from Toyota, which was allegedly inspired by the supermarkets’ way of managing their inventory of goods on the shelves: Not too much, not too little, constantly adapted to the needs of customers and on the shelf – just in time. In other words: Agile.

The Agile Board and prioritisation of tasks are the key tools. On the Agile Board, it is visible to everyone, for example with Post-it notes, which tasks are prioritised and whether the individual task is on the “To-Do list”, “In progress”, “Undergoing test” or “ Finished”. Tasks that are not on the Agile Board do not have to be solved here and now.

Please see the example below of how the Agile Board is used with input from User stories.

“Agile Board” adopted from Digital Business Models for the Future under license CC BY-SA 4.0

Note that the tasks are not necessarily solved in numerical order.
Tasks on the “To-Do list” are prioritised and must be performed. Gradually, tasks on the board are then moved from “To-Do” to “In progress”, to “Undergoing Test” and finally to “Completed”. In this way, both prioritisation, flow and progress become visible to everyone.

Whether a task is on the “To-Do list” can, for example, be determined by whether it is part of a Use case or a User story. Use case and User story are used to describe the needs that must be met in order for the user (of what is being developed) to obtain the desired experience in a given situation.

The Agile Board is a relatively simple tool, which is based on the processes and work areas that you know and already work with. The introduction of the Agile Board does not require that you ‘refurnish’ all your processes; instead, you can adapt your agile process to the situation and to reality.

In reality, the focus of the agile development process is on just a few aspects:

• Visibility about the work that the department performs
• Prioritising tasks to focus on doing what is necessary and nothing else
• Flow in the execution of the work because you remove bottlenecks
• Openness about who does what
• A stop to unproductive and frustrating multitasking – in other words: Stop commencing everything at the same time and instead focus on finishing what you are doing
• Ongoing feedback on the department’s collaboration and efficiency

This can be achieved by using the Agile Board. The benefit is higher productivity, fewer mistakes and greater employee satisfaction.

If you want to know more about the Agile Board, please see the Implementation module and learn more about how to use the tool in different ways.

Scrum

Scrum is an effective method of managing the entire agile development process, and it can be used to ensure the subsequent developmental maintenance of the result. Scrum is primarily intended for complex products and solutions, but the method can easily be adapted to the development of less complex things. Originally, Scrum was intended for software development, but today the method is used across all industries that develop products, and it is also combined with other methods.

With Scrum, the entire development process is divided into short and time-limited sequences called sprints. Each sprint is characterised by the fact that the tasks to be solved and the goal to be achieved in a sprint are clearly defined and that the result of a sprint can be launched, for example, as a sub-functionality in the overall product and thus create value immediately after the sprint is completed.

During a sprint, all participants meet daily for “the daily scrum”, which is a short meeting where each participant very briefly – for example within one minute – gives a status of tasks performed the previous day, today’s planned tasks, and whether help is needed for anything. Status, today’s challenges and any changes are discussed under the guidance of a permanent “Scrum Master”.

At the end of each sprint, a “sprint review” is held where the results of the sprint are reviewed and where the list of remaining tasks is adjusted. At appropriate intervals, a retrospective meeting is held where the focus is especially on learning from the process and on using the learning afterwards.

Each sprint starts with structured planning where employees involved in the tasks can contribute. The result is a list of the prioritised tasks in the upcoming sprint. The list is called a “Backlog”. It corresponds to the “To-Do list” in the Agile Board. Input to the tasks to be solved can, for example, come from Use cases and User stories. During the sprint, the tasks on the “Backlog” must be performed – and only these tasks.

User stories

Use cases and User stories are two methods to identify and describe which user needs that must be met. The goal is to ensure that the user of a product, a functionality or a service gets the experience that the supplier aims for. Ultimately, it is about ensuring that the user acts as desired and that the supplier obtains the intended result.

The user needs, which were identified through Use cases and User stories, can be used as input to the agile development process and the Agile Board, which is described earlier in the module.

Using the “story form” format

A User story is a short description in story form of, for example, what a customer should be able to do and achieve when he or she visits a web page or perhaps uses a particular product. The focus is on what value or what result they achieve. A User story should always be written from the user’s point of view and in the language that the user is expected to have.

A User story is often based on a format originally developed by Mike Cohn: “As an [actor] I want [action] so that [achievement]….”

An example of this could be: “As a [user of this new email application], I want to [add different tabs to my messages] so that [I can control which messages are displayed on the screen]”.

A User story serves to identify which functions, data, functionalities etc. are necessary in order to meet the user’s requirements and expectations, and the results are used as input for the further development process.

“Metal and tools web shop scenario” adopted from Digital Business Models for the Future under license CC BY-SA 4.0

The illustration above is a web shop scenario from an online metal and tools store, that can be used as input to User stories. The line MVP (Minimum Viable Product) separates what is necessary above the line from any additional things below the line.

Although a User story should always be written in story format (which can take many different forms) and from the user’s point of view, one can often use a form to collect the results because it makes it possible to add additional information to the story.

In the example below, you may let yourself be inspired by how the tool can be used.

“User story example” adopted from Digital Business Models for the Future under license CC BY-SA 4.0

User story
Print-friendly version of the tool in large format.

Practical information

• In the work of defining User stories, you should, as far as possible, always involve real users in the descriptions of roles, actions and requirements, and preferably involve so many users that the result becomes representative.
• Be prepared that the description of a User story may take time.
• Be prepared that the descriptions in a User story often develop continuously, and therefore it must be revisited regularly and perhaps updated with new information.

Step-by-step guide

1) Start by defining the role that the current User story is about. Describe the person behind the role with all the relevant characteristics, e.g. age, attitudes, hobbies, needs, dreams, employment etc.

2) Then give the role a name (and write it in “In the role of”)

3) Now describe the action that the person wants to be able to perform. Describe the action from the user’s own point of view and with all the information and details that are relevant to the situation. (Write down the action in “I want to”)

4) Describe the result that the person in the role wants to obtain from his/her action. Include all the information and details that are relevant in the situation (and write it in “In order to”)

5) Then describe the situation based on your description of role, action and desired result, and write the description in the field “When” under “Accept criteria”.

6) Describe the user’s action seen from the outside in the field “and” under “Accept criteria”.

7)  Describe the desired result of the user’s action from your point of view in the field “then” under “Accept criteria”.

8) Prioritise this user story over your other user stories.

9) If necessary, put a time estimate on your user story, which indicates how long it will take to develop

10) Finally, give your user story a title.

Use cases

A Use case is a description of the interaction between a system – it could be a piece of software or a physical product (or several products) – and one or more persons or other systems; both the persons and the systems are then “users” in the current Use case.

Use cases are most often written as structured documents with a description of e.g.:

• The goal of the Use case
• User or users
• Preconditions (what has already happened in the system; the current state of the system)
• The standard course of action or the primary success scenario (what would normally happen, described step by step)
• Alternative or extended courses of action
• The final conditions (what has happened in the system when the last described steps in the course of action have been performed)

Very often, visualising the usage situation along with the descriptions is a very effective way. Find below the illustration of a Use case that describes the interplay between a system, in the form of an online store, and people, in the form of customer and company.

“Use case” adopted from Digital Business Models for the Future under license CC BY-SA 4.0

Like User stories, Use cases serve to identify which functions, data, functionalities etc. that are needed in order to meet the user’s requirements and expectations, and the results are used as input for the further development process.

Use case or User story?

On the surface, Use cases may seem to be a more efficient way to identify the necessary inputs for a development process because Use cases are more focused, framed and accurate.

However, one should be aware that for exactly the same reason, Use cases cannot always be used to capture user requirements that are not clearly formulated – perhaps because the user cannot formulate them clearly – but which can, nevertheless, be absolutely central and crucial for the user and thus also for the success of the final solution. Therefore, it is not an “either/or”, but a “both/and”!

Output

With agile development – regardless of whether you use the Agile Board or Scrum or a mix – you get a method to control the development, which provides visibility, prioritisation, involvement and openness in the process. Relevant and elaborate User stories and Use cases provide a real understanding of and insight into customers’ and users’ needs and expectations, which is a strong basis for developing solutions that will work in reality and be well received by users.

Expert advice

• Always test continuously – including in relation to users/customers
• Involve specialists where relevant
• Be very clear and specific in your definition of when something is “finished” concerning tasks, processes, results etc.
• If necessary, introduce new development processes in “chunks”, i.e. one process at a time

Next step

In parallel with the construction of new and more flexible working methods, it is relevant to test the elements in the business model that have just been designed and are under development. This can be done through Early Usability Testing and Prototyping, which can provide insight into the customer’s experience of the specific solution, and it can be done through Internal Validation and Testing, which can provide insight into whether your company has the internal properties needed to realise the newly developed business model.

Ultimately, the goal is for your entire business model to be tested to maturity where you are ready to move on with its Implementation.

The content elements above have been developed through two projects:

‘Digital Business models for the Future’ by Aarhus University, Aarhus School of Marine and Technical Engineering and Danish Technological Institute supported by The Danish Industry Foundation. The material from this project has been adopted in alignment with CC BY-SA 4.0

‘EU-IoT’ by Aarhus University, Martel Innovate, Netcompany-Intrasoft, Fortiss, BluSpecs and funded by the Horizon 2020 Framework Programme under topic ID ICT-56-2020, grant ID 956671.