Managing Assumptions in Agile Software Development Projects

How assumption logs help me keep my projects on track.

Illustration by Vanko Yutian Zhou.

If a person steps out of their house on a fine summer day without an umbrella, rain boots, a raincoat, or anything that could help with the rain, perhaps it is because they assumed there would be no rain on that day. They could be correct and intentional, having checked the weather forecast. They could also be oblivious to the possibility of rainfall right in the middle of summer. We make many decisions of this nature every day, implicitly relying on premises that we believe to be true or false.

In projects, we must establish if we rely on verified and factual premises before making decisions.

An assumption should not be implicit; but rather, it should be explicit. It should not live in the minds of the project stakeholders; instead, relevant stakeholders must write and share it so they can validate it as true or false.

Assumptions can generally fall under four categories:

Table 1: Explicit vs. Implicit and Supported vs. Unsupported assumptions.

1. Explicit and supported assumptions are explicitly stated in a document and shared amongst stakeholders. This category is the best a project manager wants all premises to be.
2. Implicit and unsupported assumptions are the worst, as they are baseless and not documented. They pose the biggest challenge to any project, especially if the stakeholders holding them have a strong influence on the project.
3. Implicit and supported assumptions pose some risk to the project as they are essential facts that could impact the project’s direction when shared.
4. Explicit and unsupported assumptions pose negligible risks to a project because they are documented and potentially easier to weed out during the validation process.

Why are assumptions critical?

The first project I led at Doctolib was a project my team inherited. The other team planned the project, and we only needed to implement it, or so we thought. However, several months had passed since planning and execution, and a lot had changed. I had allowed a couple of implicit assumptions to go unquestioned, which haunted the project as new problems surfaced.

It later became apparent that the better approach was to re-plan some parts of the project. The indication for what needed to be re-planned could have been given by a properly managed set of beliefs about the project, as it is easier to spot explicit assumptions when they become obsolete.

Poorly managed or wrong assumptions are also significant causes of bugs in systems. Engineers build software believing it should work as expected. However, the developer must make some assumptions about the users and how they use the software, the programming language, the platform on which the software runs, and more. Failure to make the correct assumptions will eventually lead to unexpected behaviours.

A wrong assumption about assumptions.

The word “assumption” is sometimes attributed to something taken for granted. While this could be true for some assumptions, it is not valid for others. One way to look at assumptions is to see them as axioms, beliefs, or postulates that we take to be true to move forward with a decision.

An example is the idea that a product user must have a name. There might exist a human somewhere who has no name, but if our software has to be able to address people by their names, we have to assume that all users must have a name. This decision might not be accurate in the real world, but it is true for our system.

Managing assumptions.

Now that we know about this beautiful tool known as assumptions, how does one use it correctly? Whether you document it or not, you will make assumptions. The worst that could happen is making the premises for your decisions implicit without a firm basis.

Project managers use an assumption log to record and keep track of assumptions made during a project. This document allows for implicit assumptions to become explicit. A critical element of the logs is to assign each belief to individuals with additional information, who can then validate it as true or false.

Preparing an Assumption Log.

You could find a couple of assumption log templates when searching the internet. However, they might serve a different purpose than a software engineering project using an agile approach. I use a template I created on our documentation tool, Confluence. It could be more sophisticated, but it does the job for me.

Table 2: A sample assumption log for a “Project Identifiers” project.

1. The “Date identified” column is for the date of the recording of an assumption.
2. The “Assumption column” states the belief with a description. I prefer to write it down as a statement of fact and not a question. I found out it makes people react faster, especially if it is untrue.
3. The “Validation by” column states the person responsible for validating the assumption.
4. The “Due Date” column is when the assumption is due for validation and subsequent review.
5. The “Valid?” column is where the validator validates an assumption as true or false.
6. The “Comments” column is where a validator can add additional comments.

It is important to note that assumptions are not forever. There are reasons why a correct idea might become invalid. Some reasons are new government regulations and a change in the infrastructure where software runs. Therefore, the dates on the log are reference points to when this assumption was made and considered valid.

Conclusion.

Everyone involved in a project has their beliefs about its different components. It is essential to make identified ideas explicit in a document known as an assumption log, which is then shared amongst the stakeholders for them to be questioned and validated. Failure to do so allows for differences that might hurt the smooth progress of the project.

While validating beliefs in the assumption log is a significant first step, the project team must continuously analyse and evaluate them to ensure they are still relevant.

Many thanks to Aleksej Parovysnik and Laura Vavasseur for the reviews.