Tell me what you know – a different way of looking at requirements discovery
The legacy of the linear requirements process
When I started out in software development, we had a thing called a Requirements Specifications Document. Business Analysts would spend a very long time gathering the requirements, organising them, and writing them down in a large Word document.
Over time, folk found this approach to be inefficient and wasteful. It assumes that we know all there is to know about a project at the start of the project. It also assumes that writing down the requirements is the best way to transmit them into the heads of the developers. Both of these assumptions are demonstratably false.
Still, in many organisations today, even those claiming to practice "Agile", requirements definition can be a very linear process. The Business Analysts still gather the requirements and write them down in some form. Only now we call them "Epics" or "User Stories", and record them as JIRA tickets.
Now don't get me wrong; writing user stories in JIRA is certainly a step in the right direction. It moves us away from the dangerous illusion that we can know all we need to know at the start of a project, precisely the point when we know the least.
But there is more to effective software delivery than just breaking requirements down into small chunks. The best software teams also share a deep understanding of the business goals they are trying to achieve.
And that doesn't happen by accident.
Active Learning
There are many ways you can help build this deep understanding. I've had a lot of success with simple techniques such as Impact Mapping, Example Mapping and Feature Mapping. All of these are quick and easy-to-learn ways to get a clearer understanding of the business needs and of what features might help meet these needs.
In most requirements discovery sessions, the product owner (or a BA acting on behalf of the product owner) takes the lead. They explain what needs to be built, and the team listens. Then the team might ask a few questions. Two or three people do the bulk of the talking, and everyone else just listens. The others are not actively engaged. They contribute little, and take away only a fraction of the information.
What can we do?
Tell me what you know
One exercise I have started doing with some of my teams is to flip things around a little. It's an approach I call "Tell me what you know".
With the "Tell me what you know" approach, the aim is not for the product owner to tell the team what to build. It is for the team to convince the product owner that they are ready. In other words:
1) That they have understood the problem that needs solving
2) That they have a good idea of how they will solve it,
3) And that they know how to prove when they are done.
Of course, the Product Owner or BA will still need to present the problem. The developers and QA folk will explore the requirements using concrete examples, looking for variations, assumptions and edge cases, using Example Mapping and/or Feature Mapping to make the results more visual.
But there is a subtle difference with "Tell me what you know". The meetings become more balanced, and the team members become more engaged. After all, the meeting is not over until they have convinced the product owner that they are ready to start.
This works best when the team has already built up a good knowledge of the domain and of what they are building. During the early stages, they will need more guidance and explanation. If you have a reasonably mature team, why not try it out!
Related Events and Workshops
Low Tech High Impact Sprint Planning
Set your team on the fast track to delivering high quality software that delights the customer with these simple, easy-to-learn sprint planning techniques!
BDD in Action: Mastering Agile Requirements
Focus on the features your customers value the most by building a shared understanding of the real business needs, and empower your teams to deliver more optimal and more reliable solutions sooner!
