Photo by Sandy Millar / Unsplash

Question Transformation 1 – Changing the Question Word

Questions Workshop Apr 21, 2022 (Jun 5, 2022) Loading...

Background materials to the Questions Workshop

Let's take a question, and unpick it.

In this, I'm going to unpick the question by changing how I phrase it, and we'll see how that changes its use.

How do you track requirements?

You might use this question when you're finding out about your new project, or you might have it as a checklist question for yourself. Perhaps you've asked it as an auditor, or as a prospective client. In all these senses, you're interested in whether there is an answer, and in how requirements have been tracked in this situation. For different contexts, see the end.

Let's look at some common changes.

There will be some grammar, below. It needs to be English grammar, as that's my sole area of expertise. Those of you lucky enough to understand more than one grammar will be able to recognise similarities and might teach me about differences. Personally, I always have to think twice about adjective vs adverb (and left vs right, as it happens, but never up vs down), so let's hope that grammar-jargon below is minimal and mostly-correct. If you see an error, claim bragging rights and help me out by letting me know.

Removing the Question Word

Let's get rid of how.

Do you track requirements?

This is now a yes-no question – one which restricts the response to a simple  choice. You ask this if you're looking for a brief and clear answer. Perhaps you've got a [[followup question]] ready to go. Perhaps you'd consider skipping straight to a follow-up question. For example, "What requirements do you track?" will encourage fact-based answers and open conversation, and it'll detect "none" just as well.

You're also sending a signal that you're not interested in listening to the answer: you're giving the information that you're not (yet) going to put the effort into parsing anything at all complex, and that you've already got a model that is guiding your interview.

Tell me about tracking requirements.

This is now an open-ended request. You've passed the conversation over, and indicated that you're going to listen to the answer.

With so little guidance about your expectations, you'll need to work to parse the answer.

Worse, you're open to misinterpretation, especially if you have a different understanding of vocabulary and intent. I asked (something like) this once, and was told (something like) end-user expectations for tracking a parcel. If your open-ended request relies on tone of voice in conversation, you'll need to make your request more precise when writing – and readers may skip the precision anyway.

Worse still, you'll need to stop someone mid-flow if you realise that you need different information. You need project specifics – you get organisational strategy or a rant on requirements. It's your choice to stop, or to hold tight until the information you need is on offer. As with misinterpretation, this situation is worse in correspondence; your responder has already taken their time to gather irrelevant information and to write an unusable answer.

Some might argue that, without a ? or a question word, it's hardly a question at all. So I've called it a request, here. The phrase open-ended question has been taken, anyway, and means something else. Let's move on.
You might keep it as a question with "Can you tell me about..?" or "Would you tell me about..?". Be aware – you're indicating a YesNo, but 'Yes' is useless. Q: Can you tell me the time? A: Yes, I can.

Getting more specific with a different question word

Question words have a simple mnemonic, and it's tempting to think of them as  the fundamentals.

Who, what, where and when tend to lead to specifics – and so take the assumption that whatever you're asking about is done at all. Specific answers are factual, and so tend to be true (as contrasted with hand-wavy). Listen for doubt as well as information, and see whether answers match up across different people, and different days.

Though question words look simple, their use in questions is more complex. I find that thinking of purpose helps more than thinking of vocabulary. We're dealling with the following here, and I'll expand to a couple of examples for each.

Who – personnel, or responsibility,

What – tools (as in mechanism), processes

Where – tools (as in medium), trigger

When – what situation, how often, trigger


Who tracks requirements?

To identify the thing which takes the action. May be individuals or roles – and let's face it, we personify systems, so can be another system, too. Can help to detect something that's not done by anyone/thing, which can be important.

I've been in situations where I've asked "do you X?", and followed up with "who does X?", and the 'who' question has revealled that the answer to the 'do' question was unquestioned wishful thinking.
Unquestioned wishful thinking is Not mendacious bullshit. The person I was talking with believed that their organisation did X, but started to realise that, if they couldn't say who did it, perhaps it didn't. You know how that feels...
Who do you track requirements for?

To identify who cares. May be individuals or roles, often distant or un-nameable. Works as a more graspable "why". This is a question which asks about audiences / consumers / stakeholders, so can help when you're understanding how a team sees its context.


What requirements do you track?

The most-obvious follow-on question to "do you X" is "what X do you do". It's handy to use to get

What do you use to track requirements?

What do you use to... finds information on tools and methods. Can help

What do you do to track requirements?

What do you do to... finds information on process and people.


Where do you track requirements?

If you can map it, you can ask "where". Asks for a location – recognise that a location can be a country, a department, a room, a tool, a specific file – even (like when) a point on a calendar, or (still like when) a project context that triggers the action. "Where do you track requirements?" "Any work on new modules".

May be equivalent to

What (tool/capability) enables you to track requirements?


When do you track requirements

If something can switch state, then time is important and you can ask "when". You ask when if you want a clock time, a calendar date, a relative day or periodic event – and you're also asking...

Under what circumstances do you track requirements?

Getting more general with a different question word

When you're done with the facts, go wide with why and how.


Why do you track requirements?

This is the big one.

Flipping to why from other question words makes your question about values and fears, rather than about actions and tools. "Why" questions also conjures existential dread, and can lead to fights (and hugs) if used in group settings.

It's kinder, more personal, and gets clearer answers to adjust "why" to:

What are your aims in tracking requirements?

Asking it may give a different answer every time, especially if you're asking different people. It's good for finding values, and for checking consistency of values across teams, between departments, up and down the food chain of management.

If you're asking someone who thinks by talking, and who feel that they are making a difference, "why" is an invitation to improvise and invent. The person you're talking with may have new insights as they answer; they'll own the insight with delight, and thank you (on the inside) for bringing them to it. Listen for general principles, especially ones that are new to the speaker.

If you're asking someone who doesn't know, and doesn't care, and who does what they do because that's what's expected of them, "why" may put them on the defensive. Listen for deference to authority.

"Why" to a physicist (when talking Physics) invites a deep dive into fundamental universal principles. Software, and software testing, doesn't have natural laws. Organiations have history, and markets have regulations. Both are important – and are human-made interpretations of actions, fears and desires. As such, the source of the "why" is the action and its contexts, the humans who fear or desire. When facing a wooly model, you should trust clear constraints over hand-waving generalisations.

It's crucial to ask why, but you may well find that you're the one who is expected to have the answer.


How do you track requirements?

With how, we're back where we started – with a question that typically asks for a process, or instructions. How asks for practicalities, for processes, for the resources which enable a capability.

Be careful of asking 'how' and 'why' as rhetorical questions – you may genuinely not be able to see the mechanism or the rationale, but you're also imposing your model on the question.

I use an expletive heuristic to swiftly trigger my better judgement – I imagine substituting 'how the fuck'. If it feels all wrong, I'll  retreat from how and explicitly say in what way do you track requirements. There are less-sweary alternatives if you feel the need to say this stuff out lound.

How much

How much do you track requirements?

Y0u're asking for a narrative about decisions and judgement, asking about limits and context. How much is a great question to elicit strategy and values alongside methods. But, as it implies some sort of a scale, doesn't fit everything.

Be aware, when you're asking, of the differemt iuntis and scales you may be asking for. Are you asking for a quantity, or a frequency, an absolute or a rate of change?

Member reactions

Reactions are loading...

Sign in to leave reactions on posts



Sign in or become a Workroom Productions member to read and leave comments.

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.