Wisdom From a British Rock Band
"We know that you believe you understand what you think we said, but we are not sure you realise that what you heard is not what we meant."
About a decade ago we were holding a business rules and business rule technology training session for a client and kicked off the presentation with the above quote. As can be expected, it drew quite a bit of laughter from our varied audience of subject matter experts, analysts, project managers, developers, and testers. The fact that everyone laughed is a testament to something we all know to be true: Communication is hard and in many cases, taken for granted. We may feel certain we have absolute clarity, when in fact, we do not. This is still the most challenging area of the software development life cycle: identifying our real problem and communicating what we need.
What Exactly Is the Problem?
Even when the sender and recipient possess a mutual understanding of the problem, it is still possible the sender's perceived problem really isn't the problem at all! Or, it is a problem that belongs to someone else. Gause and Weinberg's Are Your Lights On is a collection of stories, each one informative and entertaining, and each addresses the nature of problem definition. The title story is about motorists who have a problem: dead batteries from forgetting to turn off their lights. The investigation for defining the problem, determining who has the problem, and the extraction of a multitude of potential solutions all make for high entertainment. We won't spoil the details here but would like to point out two things. First, there is no substitute for having been around the block a time or two and second, iteration is the only way to truly get a handle on it.
User Stories and the Problem
User stories are currently the industry's preferred method for capturing requirements, and we're on board with them. We especially like the fact that stories are refined through iterations and that user acceptance criteria is used as a means for the team to understand and share in defining the completeness of a feature. However, even when defining user stories, there is the challenge of identifying the right stories. For companies with well-defined products, or smaller companies with a more focused vision, we find this not to be quite as much of an issue. But for larger enterprises with many integrated systems, we find the first set of user stories offered up by someone on the team to be design stories. Essentially, a story like "As X user, I need Y to do Z" if not challenged, contributes to accidental complexity (Z is artificial and a result of the existing systems) rather than solving a real business need.
A sign just outside of Craggy Flats Tunnel in North Carolina that reminded us of Gause and Weinberg's outstanding book on identifying what the problem is. What does it say on the sign leaving the tunnel?
- Led and facilitated hundreds of requirements sessions in a variety of industries for a multitude of Fortune-ranked as well as start up companies.
- Have developed a set of methods and techniques for driving out accidental-complexity problems from core business needs.
- Have used a variety of techniques and processes in defining requirements including Joint-Application-Design sessions, use-case modeling, and user stories.
- Prior to the popularity of Scrum and Agile methods, used RUP to define use-cases at the user-goal level, an artifact comparable to user stores + acceptance criteria.
- Bring a wealth of experience in helping you define a process that meets the cultural and legal constraints of your enterprise.
