Covid was and is the catalyst for digitization. The pandemic saw the rate of digitization skyrocket in businesses and especially for consumers.
Like it or not, Amazon’s sales increased 60.4% in Q1 2021.
Physical products went digital wherever they could. From car keys to postage stamps, there are more digital products than ever before. Products that we had trouble imagining using digitally in the past are now part of our daily routines.
Supermarkets now deliver their goods directly to the customer or offer a quick pickup after ordering, advertising and paying online.
But for many small businesses, digitization was also the only way to survive. Why and how do you ask yourself now? Well, because it’s no longer rocket science to open an online store on one of the many cloud platforms and see quick results. Because social media makes it possible to quickly attract attention in your own network and last but not least, because that’s exactly what end customers have been looking for.
In the past, fear of change has often slowed down the digital revolution. The global crisis has led to a situation where your customers in particular, all of us as consumers, have sought and found digital solutions to our daily problems.
In addition, new challenges are emerging. Security is one of them. Because when we talk about digitalization of products and services, we inevitably have to talk and invest in IT security. – What was I reading on a social network the other day: The whole Jurassic Park fiasco wouldn’t have happened if the old billionaire had hired more than just one IT specialist. Little joke. The movie was 29 years ago. But, let’s face it, here’s probably one example each of us can think of that could be improved on the topic of IT security, but isn’t that high on the priority list.
Every company and every department can use digitalization as an opportunity. The challenge here is the approach. Because when you approach the topic of digitization, we first have to turn everything upside down. We question everything. And that doesn’t often end up with us having a whole lot of puzzle pieces in front of us. It’s a bit like when I tell my little son to clean up his room and he’s faced with chaos and has no idea where to start. He’s looking for some structure or guidance to follow.
The good news is that there are project models to face this challenge in business in an orderly way.
Design thinking is a proven way to move out of the chaos and specify the requirements and implementation into small parts, our products.
It is a method to develop new and innovative ideas. The different phases help first of all to understand the problem, then to generate possible solutions and to develop these with the help of Scrum in prototypes.
The user is always in the foreground. He is the heart of the process.
Design thinking also means that there must be constant feedback between the developers and the users. Scrum also helps here with Daily Scrum Calls and of course the obligatory reviews and retrospectives at the end of each Sprint. But more about Scrum, terminology and the processes later.
The Design Thinking approach helps us to break down the big picture into small parts, our products, to organize and structure them and then to work through them continuously. Here we get the first practical results in a very short time and can evaluate them.
The Agile Framework is not a witchcraft that only crazy startups in Berlin Kreuzberg use in a CoWorking space. No. Quite the opposite. Very traditional companies use Agile approaches to face transformation. This is because agile transformation means making a complex change that affects not only the IT organization, but the entire company yes, in the best case, the request for change comes from the business and not IT. A commitment from management is therefore a necessary prerequisite for the success of any change.
Expect the Agile Framework to be a collection of methods and tools that guide and continually challenge projects. Not every method is suitable for every use and even our proven Waterfall Model can and will be integrated at one point or another.
The methods and tools differ in Daily Use, Project Use or Product use. Depending on what we want to achieve and what the application purpose is.
In the Daily use we find methods and tools, which we can use independently of the project all daily. Among them we find Kanban Boards, User Stories, Canvas and many more.
I use these daily because they all serve collaboration. Collaboration within the team. The documentation of progress and expectations. So, especially in times of pandemic, when we can’t sit together often, they help everyone to cope and manage the daily work packages.
But in this blog today, our focus is on project and product use. Because that’s what I do. Developing and implementing Customized Products with and for my customers.
That’s why our focus today is on Scrum and the Use Cases. And now, it should be clear why we named the blog “Bridging the Gap”, because Use Cases help to build a bridge between the user and the goal he wants to achieve and IT.
Scrum is one of the best known agile approaches and has been proven many times. The fundamental approaches come from physical product development. But Scrum, as we know and use it today, is designed to develop software or to customize it. The starting point for the development of Scrum in the 1980s and 1990s was that a software development could not be precisely planned from start to finish. This has not changed until today. It is simply not possible to implement all requirements for complex software solutions 1:1 in one go in the given time. If you try this, you will quickly realize that time is running out and when the product is finally ready, it is already obsolete.
That’s why product development in Scrum is done iteratively in feedback loops of a maximum of 4 weeks, the so-called sprints. In each sprint a usable product version should be created, the increment – increment because with each sprint a part is added to the final product. This way you get fast feedback about the new function. It is important to already add to each use case you are considering how you want to measure its success. Because if it is not successful, it can disappear again or must be changed.
Scrum does not provide for projects, in the actual sense. With project glasses, Scrum could be interpreted as each sprint is a self-contained small project. There are requirements, a planning, the work in the sprint, a joint assessment of the results and a “lessons learned” or reviews.
Essentially, there are three roles in Scrum. The product owner, the scrum master and the developers.
The Product Owner collaborates based on the vision of the company management or the requirements of the users from the respective departments, trying to figure out how the desired product could look like and what, for the users will be the most valuable features. The product owner describes the functionalities to be developed in the product backlog as a use case. This is the worklist for the development team and is consistently processed by them in the specified order and priority. These processes are the sprints. Here, of course, it must be ensured that first of all the basic lengths of the software are available. Perhaps, in a classic waterfall project, one or the other prerequisite must first be implemented. For example, the provision of HW, SW or databases.
The product backlog will not be complete when the project is started. So it will not contain the complete scope as before. A worklist for one to three sprints is sufficient. The product owner gradually fills up the product backlog based on feedback and new requirements.
Sprint planning takes place at the beginning of a sprint. The product owner presents the prioritized product backlog to the development team. The development team decides independently how many of the highest-priority requirements it can implement in the upcoming sprint, incorporates them into the sprint backlog, and plans the activities in the sprint.
The Sprint Backlog represents a largely stable worklist for the sprint length, while the Product Backlog absorbs the dynamics of the environment and keeps them away from the development team. The Product Backlog can be changed at any time by the Product Owner.
In the sprint review, at the end of the sprint, the development team presents the increment, i.e. the increase in functionality, to the product owner and, if necessary, other decision-makers. These review the increment and create new entries for the product backlog if necessary. There is no formal acceptance known from projects. The sprint is not extended under any circumstances. What has not been completed is returned to the Product Backlog and is thus available again as a worklist.
Finally, the sprint retrospective takes place, in which the entire Scrum team analyzes the development process as well as the collaboration in the previous sprint and, if necessary, decides on measures to improve the organization of work. The sprint ends with the end of the retrospective. Immediately after that the next sprint starts, again with the sprint planning often this is thus summarized in a full day meeting.
Phew… that was a lot I know. But we need to fundamentally understand what a use case leads to, so we understand what we need it for and why it is so important. Because the old rule applies here too: “Garbage in – Garbage out”.
So let’s move on to the use cases. A use case describes the intention and its effect. An interaction of an actor with a system and its owner in a very simple and figurative way. The use case helps the product owner to ask “smate” questions. This way he can make sure he has clearly understood the requirement in a simple way.
But what’s the easiest way to do this? There are a few basic themes to each UseCase. The Groundwork. This usually follows a simple table with the most important information about the Case. This includes: a title, a simple description of the goal, an area and possibly sub-areas it affects, a responsible person from the area, possibly other use cases that belong to it, the traceability and, last but not least, the possibilities to measure the success and how this should happen. In other words, the key performance indicators. This should form the basis of an idea and should not be too difficult. – By the way, this doesn’t have to be filled out and discussed right away as the first thing. Some points may only become clear after visualization and can be written down. Others may need to be developed along with the use case. Like for example the KPI’s.
Only now does it get to the actual capture of the Essentials. The important part of the Essentials, and thus the entire Use Case, is the visualization model.
There are only three essential core elements in the visualization model. Let’s start with the actuators. As actuators we refer to all people, organizations, devices or other systems that have an influence on our system. – We have our, to be developed, system. That is our focus area and last we have the relationship, Relationships in between.
Let’s go through this with an example. We want to build a simple web application and our example is about a user’s login.
So we have a customer as an actor. This one makes a page request in our system. Since it is a protected system, the first thing he is asked for is a user and password. So we see the page call with a so-called standard relationship. This gets to the base use case page call. From here it continues in an include relationship to the password entry, which is a separate use case. So far so good. Now this is only good as far as the customer might have to do a bit more. E.g. get an account first. So here we have another use case. And already a second actor comes into play. Namely the admin, who needs a use case to create an account. So much for what we call the Happy Way. So everything goes as expected and smoothly. The customer has an account and can log in. Application ready to go. – Well, we all know that’s not reality and people forget their password. So let’s look again at the usecase case “Enter password” because it now gets an extension. Namely, exactly when the user enters his password incorrectly. We call it authentication. The consequence is a new use case “Lock Account”. This comes into effect when the user has entered his wrong password 3 times. This process has to be handled by an admin. That’s why he gets the direct relationship to it. To do this, he gets a new Use Case namely Unlock Account.
So much for the visualization model. But the essentials include a few more important points that need to be described. First of all, the Requierments. So everything we need to serve the use case. This can be SW, databases etc. Second, a description of the “happy way” so a writing of what happens in the best case. It can also be colored into the visualization model. This makes it clear once again what is actually supposed to happen. In addition, an alternative process must not be missing. In our example, an alternative process for authentication could be that the customer discusses this by phone with an admin and authenticates himself there.
Now I have written a lot, but actually the picture is now clear for everyone what should happen with our use case. No matter if developer, admin or customer. Everyone understands what is supposed to happen. And right off the bat. Of course, this is a rather simple use case, but it illustrates how we can use use cases to build the bridge between the requirements and the developer, who writes the code and, in case of doubt, does exactly what he is told to do. No more and no less.
Digitization cannot be stopped. Seize the opportunity. Because it is one. For every company.
Don’t look for a reference, be one.
Use Agile methods that lead to fast results and deliver a completely new view on your customer contacts.
Because the Design Thinking approach puts your customers and employees in the center.
With Use Cases we ask smart questions. It’s not about a product or a feature. It’s about what we make of it together.