Big Wall Estimation

Technique

A Big Wall Estimation takes approximately one hour and you can achieve a first high level estimation of a whole epic up to hundred stories.

Steps:

• Set the stage
• Understand complexities
• Estimate the backlog

1. Set the stage

The development team is gathered in front of an empty wall. It starts with a brief introduction of the process and the business and user values this feature will create (goals). If the stories are prepared as Story Map the User Journey is briefly presented without going into details. Additionally you share relevant prerequisites that will have an impact on the estimation.

(For example, if you build an product overview and the data is retrieved via API it will be relevant for the team to understand how many products should be shown and will be retrieved via API.)

2. Understand complexities

The facilitator calls out three stories from the Story Map at a time and puts them on the wall. To present the intended user flows and UI it is helpful to draw simple wireframes on the wall. Don't use hi-fi mockups as this estimation is about functionality and detecting unknowns. If you use to detailed mockups this will immediately trigger detailed discussions and distract from the desired outcome.

The team starts discussing and grouping those stories in terms of complexity:

• stories with a small,
• medium or
• high complexity.

Then the next three stories are called out until all stories are finished. It is important to understand that the stories are referenced in complexity against each other. The wall itself becomes the point of reference for all the presented stories.

The whole process is about momentum and speed. Hence, the facilitator puts any story that triggers a longer discussion to the parking lot to deal with them at the end of the session.

3. Estimate the backlog

After the complexity chart has been created, the actual estimation takes place: the facilitator quickly draws a table with the agreed story size numbers (e.g. 0.5 | 1 | 2 | 3 | 5 | 8 | 13) on the wall.

The team takes the stories from the complexity chart and moves them to the corresponding table column. Usually you start with the simple stories and tackle stories with a higher complexity later.

This is the second round of reflection for the team. In the first round it was all about understanding complexities. Having build up a mental map of all stories the team is able to reflect once more if the complexity in the first round was correctly assumed and can then put the stories in the correct bucket.

The Big Wall estimation is a very fast technique but there are quite some challenges and the outcome depends a lot on good facilitation.

For stories where we lack understanding we create spikes. Those are timeboxed research activities to solve problems. If the team cannot estimate certain stories you can propose a spike to solve the issue and then based on the assumption that we will know how to solve the issue the team can continue to estimate the stories. The dependent stories are flagged.

When to use this technique?

Discover uncertainties

Usually a Big Wall Estimation provides a very good first idea of the efforts to build a larger feature. Nevertheless it is important to understand that this is not about an accurate estimation but rather to discover as early as possible potential challenges and black boxes —, id est parts of the feature where the team lacks knowledge. It is about accepting that we do not know everything and to understand where the knowledge gaps are in order to start dealing with them in time when planning a first roadmap.

Indicative estimation

One thing that should be avoided is to communicate the outcome of the big wall as real effort to the business sponsor(s). If taken literally this will immediately set expectations on the funding and timeframe which can lead to very unpleasant misunderstandings. Instead it is important to communicate that the big wall should be taken as a first indication and attempt to discover uncertainties.

Proper estimations happen at refinements.

Facilitation

Job of the facilitator

As a facilitator you want to be helpful. In case of discussion you want to let it happen because the team needs to understand everything before they can estimate the stories. Knowledge-sharing can never be wrong. Additionally you don't like uncertainties and the better the estimations the better the product owner and business sponsors can plan the feature roadmap.

All of this can lead to desaster. I know it because I was there. Let us take one step back and repeat the goal of the big wall estimation: it is not about getting the most accurate estimation but to understand uncertainties and get a first indication of the effort.

The job of the facilitator is to set the proper flight level and to build up momentum.

Flight level means that you choose the appropriate detail level for the overall estimation. If you go to far into details you will not manage to estimate hundreds of stories.

Additionally you kill what is called momentum. By momentum I understand a kind of impulse, a certain movement that drives a process among people once established. In Design Thinking momentum describes a kind of bond and force that drives the participants along. I know, this is hard to understand if you have not experienced it. Just think about cycling in a group or going for a long walk with some friends. After some moments you aquire a certain understanding of rhythm and speed between you and the others. Momentum is nothing else: it is the natural flow that drives a group and it is a key skill of a good facilitator to recognize when it happens and to utilize it.

Accept uncertainties

As a facilitator you don't need to know everything and you don't need to share everything you do know. In essence the facilitator provides the framework, a quick high level understanding what each story is about and makes sure that the team doesn't go into lengthy discussions.

Whenever a story takes more time the facilitator puts those stories to the parking lot to not endanger the momentum. The goal is not to run the show but to facilitate, to guide throw the stories and make sure the team can do the heavy work. When the estimation is done you come back to the parking lot to find out how to deal with the missing stories.

Deal with uncertainties

There can also be unknowns that become blockers. For example: “Are we allowed to do this because of … security / company policies …?”.

Ask questions such as:

• “Let's assume…”
• “What would be needed to overcome this problem?”
• Stay passive and mirror the issue back to start thinking about the solution: ”What do you need that we can estimate this story?”.
• “How would you do it?”

The goal is to identify the blocker and to find a way to capture and to deal with it.

If the blocker is of a technical nature, agree on a spike:

• Define a spike that will clarify the problem
• Base all uncertain stories on the outcomes of this spike. The stories can be estimated under the assumption that the necessary technical precondition is fulfilled