[Part 5 of a 5-part series of posts about ways of being while being a Business Analyst]
I have this handy article about “Disguised Queries” that gives a great metaphor for how to talk about the differences between ‘good’ and ‘great’ requirements.
Asking people to just deliver their requirements to you, fully-formed, in the first interview is untenable. People frequently can’t think like that. It’s another reason why we stopped saying “requirements gathering” and started saying “requirements elicitation” — because the requirements aren’t laying about to be scooped up. You must prize them from people’s minds!
The cool part about the article shows that how we talk about a thing can change, depending on what we need to know about that thing, or do with that thing.
In Disguised Queries I introduced the blegg/rube classification task, in which Susan the Senior Sorter explains that your job is to sort objects coming off a conveyor belt, putting the blue eggs or “bleggs” into one bin, and the red cubes or “rubes” into the rube bin. This, it turns out, is because bleggs contain small nuggets of vanadium ore, and rubes contain small shreds of palladium, both of which are useful industrially.
Except that around 2% of blue egg-shaped objects contain palladium instead. So if you find a blue egg-shaped thing that contains palladium, should you call it a “rube” instead? You’re going to put it in the rube bin—why not call it a “rube”?
But when you switch off the light, nearly all bleggs glow faintly in the dark. And blue egg-shaped objects that contain palladium are just as likely to glow in the dark as any other blue egg-shaped object.
So if you find a blue egg-shaped object that contains palladium, and you ask “Is it a blegg?”, the answer depends on what you have to do with the answer: If you ask “Which bin does the object go in?”, then you choose as if the object is a rube. But if you ask “If I turn off the light, will it glow?”, you predict as if the object is a blegg. In one case, the question “Is it a blegg?” stands in for the disguised query, “Which bin does it go in?”. In the other case, the question “Is it a blegg?” stands in for the disguised query, “Will it glow in the dark?”
So we need to not just ask “Is this a blegg?” we need to also ask about which box, or whether it glows. The questions behind the first question are the ones to ask as an analyst.
Likewise, you will get disguised queries from clients. They will ask about the process or their concerns about requirements numbers or priorities if they are feeling like their needs aren’t being heard.
But which questions should you ask as a BA? I’m sure someone has a list of requirements questions they ask every time. I’m sure someone else published a book about the best template to use to document requirements. For me, I have two things: experience, and a beginner’s attitude.
The first one comes with time and practice, but the second one you can do right now. I ask clients to explain their business and their processes to me “as if you were explaining to a child or an alien.” I have them define every acronym, name the people or teams involved in a process, describe the goal of their task before they describe the task.
And I question everything, as a beginner would. Why do we need to track this information? Who needs to be able to access this system? When will I know I’ve completed this task? It’s partly root-cause analysis, and partly to help the person explaining to you take a second look at their assumptions. Using a beginner attitude also lets you ask what are seemingly dumb questions — and that can be really liberating! You’re a total noob, so it’s okay to ask dumb things!
The beginner attitude also puts your client in the role of mentor and teacher. It builds that vital rapport needed to do good work together. They will often feel protective of you, and invested in your understanding. They will give you context, or explain office politics, or warn you of potential pitfalls because you’re on their side, listening and trying to understand and represent their needs.
With this mindset and approach, we can get better results from whatever process, template or methodology we use to elicit requirements. It’s people-centered, focused on just enough, just in time, welcoming to change and questioning assumptions.
Other posts in this series:
- Requirements as Art (not Science)
- These Aren’t Your Requirements
- Requirements are Never Done
- People Problems, Not Technology Problem
- The Question Behind The Question