Reducing Risk during software development.

Photo by Kelly Sikkema on Unsplash

Happiness = reality/overoptimistic estimations

Developers seem to be from their nature optimistic people. Tasks always seem to be about “80% ready”. Even very experienced developers have difficulties making precise estimations. There are many things that are wrong about estimations and how we make them, but no matter how we are going to estimate, estimations are required, because we need a “plan” for when we are going to release. Company stakeholders want to see “plans” and estimations are the backbone of every plan.

Our example: a customer journey for applying for a digital loan

Let’s say that we want to plan the development for an application that allows customers to apply for a digital loan. The basic steps in this customer journey would be:

  1. Entering the key data for the loan want, these would be: the amount of money you need, the number of months you will need to pay back the loan (this influences the monthly payment of course) and the purpose of the credit.
  2. Viewing the offers you will get, after you have entered the data. Now, this is where it starts getting interesting. There are many options we can provide to improve the experience for a customer. Should we let her sort the offers? Should she be able to filter out options? Can she apply more than one filters? Should we provide the option to directly compare two offers? What about comparing three offers? There are endless possibilities we can provide to the customer, all of them increase the development time though, and also the risk of delaying the release of our software.
  3. Going through a credit check. This requires from the customer to enter the information required to apply for the credit (this includes personal information like the customer’s salary, whether she has a mortgage, etc.). Here again we have many options with the potential to vastly increase the complexity of our software. How will the customer enter his birthday? Do we provide a date picker provided from the operating system? Does the CI of our company require from us to implement another date picker? How does the customer enter his address? Is it just a textfield? Do we validate the address? Do we provide auto-completion to improve the usability of our customers?
Figure 1: A depiction of a vertical backlog.
Figure 2: A depiction of a vertical backlog with theoretical slices for sprints.

An end to end journey will not be possible, if applying vertical slicing, until much later.

It is also possible that there are risks throughout the journey of which we are not aware yet. For example are we sure that we can integrate with all the systems required in the further steps? What if for example we need some kind of authentication (which we have completely ignored in the beginning) from a user to see the result of her request? So many unknowns.

A horizontal approach for our customer journey

Let us flip the above image and think of another approach to tackle the implementation of our software. Take a look at Figure 3.

Figure 3: A horizontal approach for implementing the customer journey.
Figure 4: A horizontal approach for implementing the customer journey with a slice for an MVP.


When beginning the development of a new product, service or feature think of how you can “cut” the tasks in a way that you eliminate risks ASAP. A horizontal visualisation of the tasks you have to implement and the steps required from a customer perspective, can help you find the ideal cut. Applying a technique like user story mapping [1] can help you achieve this result.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store