Agile requirements gathering is an ongoing task that occurs throughout the build of an application or project. We never, ever, generate the full requirements up front as this assumes we have learnt everything. This is hardly ever the case as we learn as we go as we get better at the domain we are working in and the feedback we receive from users. It also means we don’t waste time on ideas that may not be needed. This great article gives more reasons as well. We must be careful to also focus on goals and avoid creating solutions (e.g. the system shall…) as we gather requirements.
One of the tools available to a team is the Requirements Gathering Workshop. This is a focused and time-boxed activity to increase our learning and understanding of the domain. Gojko Adžić has written about this quite extensively. Other ideas like Deliberate Discovery and Feature Injection assist as well. But for workshops Gojko provides solid reasoning.
I’ve summarized his thoughts on requirements workshops from his book Bridging the Communication Gap. He builds on this in his subsequent book Specification by Example. If you buy Specification by Example you can get Bridging the Communication Gap for free from Gojko. This is a summary so don’t expect a full explanation here. Hopefully you still find similarity in your own experiences and a reason to seek out Gojko’s pragmatic and useful books.
He also gives great training (from what I hear/read from Perth Western Australia – he’s in the UK). I also include this in my course on Agile Testing for which this post is also a little plug for.
- Diversity is an advantage. Avoids GroupThink and embraces Wisdom of Crowds. Diversity includes different roles, backgrounds and don’t forget the stakeholders.
- Agreement should be reached within the timebox. Max 4 hours for a two week iteration.
- Knowledge Transfer is key. It will allow suspect issues to be surfaced quicker.
- Challenging of ideas is encouraged until agreement is reached.
- Ok to come to a workshop with ideas – but they need to be critiqued.
- Go to the source – avoid third parties and telephone game info.
- Output are examples, not solutions. This will limit flow and is the wrong time to discuss solutions.
- Examples are good, the most important output is Shared Understanding
- Run Feedback exercises to measure understanding. Differences in feedback indicates misunderstanding exists
- Common Language to avoid translation between business and technical jargon. Use the language of the domain.
- Not a Meeting and favour smaller workshops to remain focused
- Not a Presentation – not how the system will work.
- Open Discussion focussed on goals
Who can Facilitate – a role for a Business Analyst
Don’t have access a professional facilitator? Got a Business Analyst? Use them. The role business analysis is transformed in an agile team. No need to fear as a BA can provide constant and valued input at an increased level of effectiveness than in a traditional process.
The role is transformed from ferryman of information using the lowest bandwidth communication (documents) to a facilitator using highest bandwidth communication (human communication face to face). Developers benefit from your valued input via the facilitation during the workshop, chasing down pesky issues, chasing greater business value. Because they don’t miss the vital points and aren’t subject to ambiguity and misunderstanding as before, you’ll have time to do this.
By automating the specification into an executable specification trace-ability is improved and tracking of progress is improved as well. Costs come down and more value is delivered quicker. Value can be created elsewhere (see the Pareto chart here).
Your confidence goes up and stress levels come down and rituals like CYAM are removed.
The role of the BA has a lot to offer in an Agile setting! Here’s a great drawing from Lynne Cazaly summarizing the role of a BA in a talk given by Bernd Schiffer and Chris Chan.