I once worked with somebody who had the following pinned up on their
wall for easy reference during the many teleconferences in which they
participated:

Use questions for clarity:

What?

Why?

How?

When?

Where?

Who?

Which?

Not a bad idea that, a little prompt to make sure you
really understand a topic. I don’t have a reminder up on my wall but I
always like to try and run through these when appropriate. (Well, and
when I remember.)

I was thinking about these in the context of agile software development,
and how they can help various roles and guide activities. Let’s look at
each of them in turn. I’m going to approach this from the perspective
of a team following scrum, but I think the general principles apply to
all approaches to software development.

Where
Is everyone office based? In the same office or spread across more than
one? Where is the customer? And other stakeholders? Some arrangements
are better than others. The answer to the WHERE question is definitely
important, but usually something few agile software development projects
can influence very much. Most folks would agree that the ideal set up
is collocation with an onsite customer. If you can get that…awesome. If
not, recognize the shortcomings and know how to mitigate the problems
they might present as best you can.

Who
The WHO question can apply to a number of things. Who is on the
development team? Who is the customer? Who are the users? And so forth.
From the scrum perspective it’s really important to have identified who
the product owner is. The product owner is such a key role for
successful scrum because of their product visioning and feature
prioritization work.

Which
I struggled initially with WHICH. It has less obvious utility than the
other questions. I think primarily though it can be thought of as your
prompt to consider prioritization. Prioritization is absolutely key in
scrum. Which projects should we fund? Which themes do we want to target
for this release cycle? Which features are of highest value? Which
features are risky or are we unsure how to do?

What
Everyone involved in a software development effort should be clear on
WHAT they’re building. Initially WHAT is primarily the province of the
product owner. They start a release cycle by consolidating input from
the customer, other stakeholders, the team, their own ideas and provide a
statement of what the product needs to do.

Why
The WHY is important, possibly the most important question of all to my mind for a couple of reasons.

Firstly it lets you check that a feature is really needed and worthy of a
place in your product backlog. With something akin to the five why’s
technique you should be able to explain the necessity for every feature
in terms of one of the following business values:

Protect revenue

Increase revenue

Manage (reduce?) cost

Increase brand value

Make the product remarkable

Provide more value to your customers

Product owners should be very clear on why anything in the backlog
is needed. If you as product owner find you can’t tie a feature to one
of the values above then you might want to ask yourself if you’re sure
it’s needed.

Secondly, once the whole team understands the WHY of a feature we can
harness everybody’s input for some creative thinking. Sometimes people
think they need a feature because they assume certain things can’t be
changed, or they don’t realize there are other ways to approach a
problem they are trying to solve. Perhaps an existing feature can be
adapted to meet their needs.

How
The question of HOW is almost as important as WHAT and WHY. Those three together form a kind of virtuous trio.

HOW is a question that cannot be answered by any one single role on a
scrum team. Everyone has a contribution to this question. As the saying
goes, there’s more than one way to skin a cat. And with software that
definitely applies. Figuring out the possibilities and weighing up the
pros and cons and trade-offs involved will help lead to the best
possible features implemented in the best possible ways.

Beware product owners that dream up the HOW as well as the WHAT and the
WHY. Unless they’re from a development background it’s likely that not
all of their HOWs are feasible or optimal.

When
Often the WHEN question is the one most businesses, customers and
stakeholders obsess over. To some extent I think this is almost
impossible to escape, although it is possible to put more emphasis on
WHAT by stabilizing the WHEN with a fixed duration release cycle.
http://www.jonarcher.com/2010/10/delayed-gratification.html

Once the team understands WHAT, WHY and HOW they can estimate the effort
involved. If the team has a stable velocity this then allows the
product owner to be quite predictive in answering WHEN and they can move
features up and down the stack ranked backlog to accommodate the needs
of the business as best as possible.

All righty then
Having reviewed all these question-words there are two key insights for me.

Certain roles on a scrum team are better positioned than others
to answer certain questions (POs have a natural affinity with WHAT and
WHY; developers with HOW)

Nobody on a scrum team has the exclusive preserve of any particular
question: by working collaboratively and with everyone empowered to ask
and answer any of these questions the talents of everyone can be
harnessed to make better software.