In most cases, BAs under time constraints start with their end-product, the formal requirements document, or perhaps user stories in a tool like JIRA. They find their standard requirements template or open JIRA and get to work, robotically cranking out requirements—usually alone, in their cube.
Then, BAs schedule a requirements review with the team. The review stirs up lots of questions and concerns which leads to a very long cycle of reviewing and re-writing. BAs get frustrated because stakeholders keep changing their minds and scope begins to snowball, downhill, out of control dashing everyone’s hopes for speedy delivery.
The documented requirements is the output, not the value we provide!
As BAs, we need to take control of that scope snowball. We need to keep its size and speed in check, so we aren’t always lagging behind. So let’s replace the image of that out of control snowball with a happy, stable snowman.
When you gather a group of friends to build a snowman, each person arrives with their own big picture. Each person comes with a mental model of what the solution looks like based on their previous experiences and imagination.
As a BA, your goal is to blend and merge these diverse perspectives and create a shared understanding of the snowman with the critical decision makers. If you start the process, by documenting formal requirements, before you reach shared understanding, you will be presenting something like this to your friends:
- The snowman shall wear a black top hat with a yellow flower.
- To keep his neck warm, the snowman should wear a red scarf.
- To keep him stable, the snowman should not have more than three tiers.
- The snowman requires a carrot nose.
- The snowman requires temperatures to remain below 32 degrees to prevent melting.
- The snowman shall smoke a pipe.
- The connection between the base and the body should be at least 4 inches wide.
Of course, your friends will react because your documentation looks nothing like their big picture. They may not be able to see how the details fit into their vision, or they agree with parts and details and then change their mind as they listen to others. It seems like they keep changing their minds.
- It’s hard for the users to compare the words to their big picture.
- They can’t easily identify gaps.
- Issues will arise, but in a random order over a long period of time.
- Users can’t see the connections between components.
Using formal text documentation to elicit requirements is not an efficient approach. Documentation may be needed as a deliverable to document the output of elicitation; it’s just not an effective process to build shared understanding. When we start with formal text documentation, we work really hard, but it’s a false sense of progress because we are not actually moving forward. We get stuck in a never-ending cycle of:
We CAN start with the end in mind, but we CAN’T start at the end if we want to speed up the process. Let’s flip the approach. Instead of spending 80% of time reviewing and re-writing, spend 80% of time on elicitation and analysis. Use collaborative techniques to build requirements with the team, piece by piece and layer by layer.
Back to our snowman. I am from Minnesota, and we could argue that we are darn good snowman makers here! We have a constant pack of snow on the ground for about 4 months of the year. I am sure others that live with snowy winters can relate!
A snowman starts with one small snowball. As you roll the snowball, layers of snow begin to stick. As it gets bigger, you need more and more friends to help you keep it rolling. Your friends will agree when the snowball is big enough to provide a foundation:
You repeat the process again for the other components of the snowman:
Every expert snowman builder ensures stability by packing extra snow where components connect:
Then, the team begins to accessorize:
At the end of the process—after all of the collaboration, models, discussion, debate, etc.—you document your requirements:
And guess what? Everyone nods their heads in agreement, without 20+ rounds of “review and re-write.”
Why is this collaborative approach more efficient than the “write and react” approach? How does it speed up the requirements process?
- It’s easier for your brain. From a cognitive perspective, our brains can’t process text well. The brain needs images and engaging dialog to work through complex ideas.
- Stakeholders participate early and often. If they participate in building the components (models, diagrams, matrices, tables) that make up the requirements deliverable, they will have more trust, fewer questions, less fear, more confidence and offer more support through the project lifecycle.
- It takes less time overall than the painful review/rewrite process.
- There’s less rework. Effective elicitation and analysis techniques make gaps, dependencies, and constraints more obvious which allows the team to manage issues earlier in the requirements process. It minimizes requirements rework generated in testing and after release.
Getting requirements done faster means more elicitation and analysis and better (more engaging) techniques.
Instead of starting with text-based requirements templates, we should use elicitation and analysis techniques that inspire meaningful dialog including visual models, matrices, and collaboration games.
It may seem counterintuitive, but spending more time on the front-end of your requirements to create shared understanding before cracking open that formally documented end state, will speed up the write/review/validate process. If you get everyone on the same page first with effective elicitation and analysis, then documentation and review become a rubber stamp and requirement processes will be more effective and efficient.
What is working for you to speed up requirements? Leave your comments below.