I work in the public sector as an Agile coach. One of the question I often get asked is how to estimate the size of a new project, or a new delivery, as we need to determine a budget before executing it.
One practice that has proven useful for this in my work experience is what I call the wall session. Tremeur Balbous roughly documented it in French on his blog in 2010. Since I didn’t find a lot of information on the web in regards to this technique, I would like to use this blog to describe how I setup the wall session and best practices I have to increase the success of this session.
Overview
Objective
In my terms, the objective of the wall session is to have a rough estimate (in points) of the efforts required to build a given set of stories for a planned delivery.
How to run a wall session
Basically, the execution of the wall session is as follow:
- Use tape to divide a wall in multiple columns.
- Use a system to identify each column.
- Example 1: Fibonacci serie (2, 3, 5, 8, 13, 20, 40, 100)
- Example 2: Pizza size (S, M, L, XL)
- Identify a story worth 5 pts (or a few) to help the team understand the meaning of their 5.
- Write a few keywords of the story on an index card.
- Stick this reference story in the column marked with a 5.
- Within a time box, iterate through each story in the backlog.
- Write a few keywords of the story on an index card.
- Stick this reference story in the column voted by the development team.
Planning
There are a few things I do before the wall session. These are:
- Identify a room with at least one large wall so we can stick our stories on it.
- Identify the rights people required at the meeting (Scrum team and others).
- Prepare the necessary material (tape, index cards, Post-It, markers).
Execution
In my experience, the wall session starts in the morning and last until the end of the day (or when there are no more stories to estimate). I do not cut the session in two, starting in the afternoon followed by the next morning. I have found that people forget stuff when they go home. The momentum of the session is also broken. The 1-hour lunch break seems a good way for people to re-energize.
Follow-up
At the end of the wall session, I distribute the stories to each team member so they can enter their points into the electronic system (if you have one). This saves some work for the PO and gives a chance to show collaboration between the PO and its development team. I will also ask the PO to communicate the total number of points to the business so it can now be aware of the size of the next delivery.
Best practices
As I have run quite a few wall sessions in the past, I’d like to share some helpful practices to help readers be more efficient if they apply this technique in their work environnement.
Times boxes
Just like Scrum ceremonies are time boxed, so is the wall session. I have found that for estimating 6 months of work for a Scrum team, a day is often enough.
Second, plan a time box for each story you want to estimate. I call this the story time box. As you are at the start of a project, you might have very few (or to much) information in regards to a story. To limit discussions at each story, set yourself a time box to force people to vote on a number and move on. The idea is not the be precise at this time in the project.
For example, if you have 80 stories to estimate during your wall session, and the time box of your wall session is 6.5 hours (removing the shuffle time, bio break and lunch), the time box for each story will be:
6.5 hours * 60 minutes / 80 = 4.875 minutes or around 5 minutes per story
If you are facilitating the wall session, you will probably get tired of reminding people that their time limit is about to end for each story. I’ve switched to visual cues to alleviate my job. For example, a timer displayed on the wall where the stories are is a good way to remind the team without you intervening. Another trick is to simply draw a line on the white board to indicate a minute has passed. The team knows that after the fifth line, time is up.
This might seem harsh on your team but I find Parkinson’s law a good reminder of why I am using time boxes:
“Work expands so as to fill the time available for its completion.”
Identify chickens
An old joke in Scrum’s early days talked about chicken and pigs. Basically, a chicken and a pig wanted to start a restaurant. The chicken suggests the name “Bacon & eggs”. The pig strongly disagrees, as he would be committed while the chicken is only involved. Pigs are the Scrum team as they are committed to the project while the chickens are people revolving around the Scrum team.
I use the same analogy during the wall session. It is possible that people excluding the Scrum team be in the room. For example, an architect wants to participate, as he would like to note new questions that are coming out during the discussions between team members.
To respect the time boxes, I ask people outside the Scrum team that they can sit in the room but they cannot participate unless the team asks for it. I ask them to write their questions down and do what is necessary after the meeting. These people are called chickens.
Closure after each story time box
I use a simple rule if we reach the end of our story time box: the majority wins. If 2 people assign 5 pts to a story while 4 are giving it 8 pts, the latter wins. I try to downplay the importance of this number. I remind the development team how we are at the beginning of a new project and this number will probably change as we move forward. In case it is a tie, I will pick the highest number, as I prefer to play it safe.
Stand up, get up
Back in 1999, the Journal of Applied Psychology published a paper entitled “The effects of Stand-Up and Sit-Down Meeting Formats on Meeting Outcomes”. The paper abstract stated that :
“Sit down meetings were 34% longer than stand-up meetings, but they produced no better decisions than stand-up meetings.”
Just like I ask the development team to stand up during the daily Scrum, I also ask the development team to stand up during the wall session. Yes, you are correct: they will stand up for an entire day. Agreed, they all end up leaning on a wall after a few minutes but they are still standing up.
Mockup to speed up
For stories that have a GUI involved, I will ask that a mockup be drawn or presented to help the team get a better understanding of the business requirement at hand. If the mockup is drawn during the story time box, I will take a picture so we can add it to the story in our electronic system later on.
A tool that I have found quite useful to create mockups in a few minutes is Balsamic.
Visualize the abstract
Just like mockups are good to help the team visualize GUIs, I ask the PO to bring diagrams when we talk about business processes. This will also help the development team understand what they cannot see. As business processes can be quite abstract, a diagram is a good way to have an agreement between team members about what they are talking about.
Final thoughts
Estimating a Agile project has always been a tough point when management looks for a budget to dedicate on the project, especially when you are in a plan-driven context like the public sector. As budgets need to be approved for the upcoming year, it is hard to conjugate estimates and budgets. I have found that the wall session is a useful technique where the development team who will do the work estimate the efforts to deliver the core business value to the customer.