Agile Estimation using Silent Brainstorming

Software development projects are difficult.  Since software consists of bits, it is malleable, and change is the norm.  Agile development methodologies do a great job addressing and embracing the natural entropy of software projects and giving us tools to harness change and use it to help us succeed.

As a project-based software development consulting firm, however, we at Yahara Software are frequently asked to provide fixed-bid budget estimates for large-scale projects.  Clearly this is at odds with a pure Agile approach, which would have us focus only on high-value near-term goals.

To address this challenge, one technique we have used to address this challenge is what I call "Agile Estimation using Silent Brainstorming".

Silent Brainstorming
Silent Brainstorming is nothing new; it's an established approach to encourage all team members to contribute to any brainstorming session.  The basic idea is to have everyone write down their ideas on sticky-notes, and then to position, group and organize the notes without talking.  We have used this technique for a long time for Sprint retrospectives; it gives everyone on the team an equal say and provides a nice visualization of your results.

Using Silent Brainstorming for Estimation
In order to create estimates, our process is as follows.  The basic idea for the brainstorming and grouping portion of the process comes from Jeff Patton's work on Agile Story Mapping, but I have extended it a bit to enable us to use the results for estimation.

Documentation Review: everyone on the team studies all project documentation (RFP, proposal, screen mockups, mind-map – whatever is provided)

• The team spends some "heads down" time studying all the information, and if possible speaking with the potential customer, to get as good an idea of the overall requirements as can be obtained at this early stage

Silent Brainstorming: the team meets for a "Silent Brainstorming" session

• Prior to the meeting, a team lead does their best to define some "broad categories" into which features for the system would fall.  These categories are written at the top of the whiteboard to form columns.
• Each team member gets a stack of sticky-notes.  They write down all the application components that they can think up for a proposed implementation of the system; infrastructure, architecture, packaging and deployment, interaction with 3rd party services, etc.  These notes are placed on the whiteboard under the appropriate category.
• After all the sticky notes are on the board, the meeting leader stacks and groups sticky-notes.  The goals of this exercise are:
  • To prioritize features – items that everyone wrote down are more likely to be "must-haves"
  • To identify missing categories – a number of sticky-notes will likely not match any of the categories initially defined; this can help close gaps in the proposal and estimates
  • To spur discussion – people may word things differently, and there may be some great discussion of possible approaches to solving problems
  • To make sure you have thought of everything – any one single person will always miss something (possibly a lot of things) when doing estimates on a large project.  But by combining the brainpower of an entire team, you can capitalize on the experiences and thinking of the whole group, and it's much more likely that someone will come up with more obscure work items that will need to be accounted for in estimates

Results Analysis: the analyst organizes the results

• The sticky-notes are collected based on category, and creates a document that groups all the note text into features, sub-features, and individual deliverables.

Estimation: the team produces the initial estimates

• The analyst can roll up the different feature areas and deliverables and produce rough work estimates; with all of the information on all of the sticky-notes, it's a lot easier to feel good about the estimates.
• Another option is to publish the document and have another meeting with the team, and use a technique such as Planning Poker to produce the estimates.

Estimate Review: the team reviews and signs off on the estimates

• At this point, the high-level features and work estimates are ready to go into the proposal document.  The team or team leaders then review the estimates again, and add in other categories (Scrum meeting time, QA, etc.) to flesh out the full project.

We have found this to be an effective process to help produce the best budget estimate based on all available information.  Of course, once the project starts and the changes begin to happen, we manage it using our Agile process, but we are comfortable that at least the initial budget estimates were based on as thorough and grounded numbers as possible.