In this blog post, I would like to share with you a technique that we have been using at Plataformatec that is supporting our teams and clients to understand the relationship between complexity and uncertainty when they need to evaluate software requirements.

If the team that you are working on has been developing items (e.g. user stories, bugs, etc.) with a high variability in lead time or, in other words, the process that you have been running allowed some requirements to be developed fast and others to take a long time to be completed, probably you are in an environment with low predictability (if you wanna read more about that, please check out “Looking at Lead Time in a different way” and “Why we love metrics? Learning with Lead time”).

During our experience with software development, we had seen that it isn’t so simple to look for items considering uncertainty and complexity (business and technical) perspectives before committing to deliver it.

The biggest problem is that undefined demands will make the process inefficient. The stakeholders won’t be able to understand team’s delivery capability and the team will spend a lot of time trying to estimate an effort of something that is, by nature, unpredictable (pieces of software).

The approach that I will show next is a method that we are applying to create batches of work items which require similar effort. I have been proposing it as an alternative to replace ceremonies like planning poker, and to reduce the time spent estimating software development items. Before describing it, I would like to acknowledge Diego Poblete (@dipoblete), who introduced me its first version.

The horizontal axis of the matrix expresses how much technical and business doubts the demand that is been investigated has, and the vertical indicates the complexity and the effort for producing the demand.

The “small” category on the x-axis accommodates demands that are well defined (success criteria are clear) and have a low amount of doubts (the item has small technical complexity). In the y-axis, it represents demands that require little effort and its implementation is not complex (e.g. the team is used to handle demands like the one that is being assessed).

The “middle” category on the x-axis accommodates demands that aren’t so easy to be developed when you look from a business and technical perspective, but the team knows how to create them (e.g. functionalities with lots of edge cases). On the y-axis, this category represents that the demand will require considerable effort to be completed but the team has the domain to do so (e.g. features that require integration with dependency systems).

Finally, the “large” category on the x-axis accommodates demands with relevant implementation doubts or business dubiety, which causes team members to be insecure, because it is something with low context understanding (e.g. new product features or changes in a legacy software). In the Y-axis, the “large” area means that a demand is too complex or will require a lot of time and effort to be completed (more than two weeks).

The demands classified on quadrants 5, 6, 7, 8 and 9 must be discussed and will hardly be ready to enter the team’s development flow. The reason? They bring a high degree of uncertainty that will naturally lead to: rework, delivery delay and other undesirable effects.

Since the goal is to create a sustainable flow, I will share some tips about how it could be useful for you:

1. Make a good refinement and discuss how ready to get into the development flow the demand is.

2. If the demand carries a lot of uncertainty, create research strategies so the team gains technical and/or business knowledge. At certain times, it is better to have people taking time to evaluate and study, rather than including a demand to be developed at any cost.

3. If a demand has an excess of business uncertainty, look for experts to mitigate it. Even though they do not know the technical vocabulary, they are extremely useful at describing the world in which the solution will be useful, and such exchange is helpful in the team’s progress.

4. Exercise breaking down large demands into small ones, even if you must deal with inquiries like small deliveries that do not add value to the business. When we break uncertainty, we are reducing risk, which, to me, represents value because, eliminating waste, we prove abstract concepts faster and validate fractional complex hypotheses.

Demands ranked in quadrants 1, 2, 3 and 4 will generally be ready to enter the development flow because they will have healthy sizes of effort/complexity and will have little or none uncertainty.

Summary

Software development estimation isn’t an easy work to do and sometimes require a lot of time and energy.

If you are a Scrum Master, an Agile Coach, or even just work in a team that uses agile software development, sometimes you will need to plan the work that will flow inside your process. Therefore, the use of techniques that help you to be faster on this kind of activity is important.

A major benefit of using the matrix is that we make people examine in more details the natural hurdle, that is, understanding the activity.

We have been holding faster meetings, while increasing the quality of our team’s discussion, because we are more focused and the communication flows better between business and tech teams.

Applying the technique will help you to decrease demands’ lead times and, as I said earlier, it could be an approach to replace other estimating techniques.

What about you? What do you think about the matrix? Did you like our approach? Share your thoughts with us in the comments below!