Agile: Focusing on the 'Why' builds better requirements than the 'What'

Note: I use the words what and why more times in this article than it feels like anyone should have to read so I apologize in advance. I did flirt with the idea of using dogs and cats, or cake and cheese, but it didn't really work.

Running a user story workshop, collecting adequate requirements, and then ensuring that those requirements are in a usable state can be tricky. Like everything, it takes practice to get it right.

Some of the most prevalent issues I have seen in Scrum projects are due to a poor backlog. Often the requirements haven’t been scoped out properly, the acceptance criteria is lacking, or the item is too large to complete in a Sprint. Generally, everything is a bit too vague to know in which direction to take the requirement in.

However, in some instances the issue is that the user story is too constrictive; the requirements are so specific that they are impossible to fulfill, or don’t leave room for the team to exercise any creativity or apply their expertise.

This can happen when, during your user story workshop, you’re letting your users focus on the what rather than the why. This is something I have mentioned in a couple of blog posts but felt it merited a post of its own.

Before I jump into this, it’s worth noting that focusing on the what rather than the why is not the end of the world. In my experience having requirements which are too vague causes more issues than those which are too restrictive.

First and foremost, you want to focus on getting your user stories at an acceptable level during your workshops so that they are of use to the Dev team. If you can’t do that for whatever reason – maybe you are new to running workshops, or maybe you are just having a really bad workshop – then don’t worry about getting your attendees to focus on the why. You will most likely end up confusing them and any chance you have of gathering decent user stories will be lost. At a base level, the what is often good enough. For some projects it may be better (I’ll discuss that below). You shouldn’t attempt the why until you are confident in your ability to be able to extract it from your attendees and leave the workshop with some useful stories.

So what is the difference between the what and the why? I will address this by using an example as hopefully it will make more sense seeing it in the context of running a workshop.

The Difference Between the What and the Why:

There is a particular exercise that I run at the beginning of each user story workshop. At first, I used it as a vision sharing exercise to ensure that everyone was on the same page in regards to where we were and where we needed to be. However, I soon realised its potential for helping demonstrate to attendees the why rather than the what and started to use it with positive results (both in terms of stories and feedback from attendees).

This exercise is simply called ‘Martin the Martian’ (and full credit to the AD of Technology at CLIC Sargent for teaching me this one).

First take a piece of flip chart paper, and near the top draw Martin (remember, he’s a Martian so feel free to give him six arms, two heads, etc.). Make sure you draw him with a sad face.

Relay Martin’s backstory to the group. Martin is going through a bit of a rough time at the moment. Mars decided it wanted to leave the Inter-Galactic Union which caused a recession the likes of which Mars has never seen. Martin was one of those Martians who suffered massively thanks to the crash. He lost his job and couldn’t afford his rent. He borrowed money off of loan sharks to try and tide him over but before he knew it he was in debt to the sharks. He then lost his house, and is now living on the streets. His parents are disappointed in him for getting into so much debt and want nothing to do with him. This is Martin as he currently is.

Draw a circle around Martin and include all of this information in the circle.

Now draw Martin again below, but this time draw him with a smiley face. Draw another circle around him. This is future Martin, where we want Martin to be. The idea is to take a look at where he is currently, define where we want him to be, and then we can start thinking about how we get him from here to there.

I take the fact that Martin is homeless and say to the group ‘OK, Martin is homeless right now. What does he need to resolve this issue, what’s the solution?’

9 times out of 10, the people in the workshop will say ‘Martin needs a house’. Which is fine, but a perfect example of people immediately jumping to the what.

At this point I ask them OK, but why does Martin need a house? The responses are usually along the lines of ‘he needs physical shelter’ and ‘he needs a permanent address to find a job’.

If we replace ‘Martin needs a house’ with ‘Martin needs physical shelter’ then we have opened our options wide up. Now we can include Martin staying with friends, or staying at a shelter, or maybe looking for a job which includes accommodation as part of the work package as potential solutions.

Remember, you can use your acceptance criteria to set the boundaries on the request, i.e., ‘needs to have four walls and a roof’ or ‘must have a secure entrance/exit’.

One of the main differences between Agile delivery and Waterfall delivery is that Agile delivers in increments whilst Waterfall delivers in more a ‘big bang’ sort of way. Agile focuses on starting by releasing a baseline – or an MVP (minimal viable product) and building it up by releasing a little bit more at a time. Waterfall focuses on building at waiting, and then releasing everyone at once as one, overall product.

Let’s think about Marvin’s journey realistically; he isn’t going to go from being homeless to suddenly having a house (unless he is extremely lucky). He is going to have to build up to it, maybe first staying at a shelter whilst he gets on the list for a council house and finds a job, then maybe he will join a help to buy scheme, and then finally buy his own house. It is this mindset that Agile attempts to encourage, and this mindset is especially allowed to thrive in environments where you are asking why rather than what.

The Benefits of the Why:

Vague user stories can cause many issues in a project. It can therefore sometimes seem sensible to have much more direct requirements such as ‘I want a house’; it’s to-the-point, there is no ambiguity, and the stakeholder knows exactly what to expect. For small or very straight forward projects this may be preferable. However, for much larger projects that cover a wider scope, such as a new website or a new intranet, then focusing on the why rather than the what can be much more beneficial.

Think about it practically; you have assembled your project team because they have expertise in different areas or with different elements of the project (at least, I hope you have). If you are building a new website and one of your stories is “As a potential donor, I want to see a picture of one of our young people in hospital at the top of the page, so that I empathize with the cause and give more money” and you hand that to the person specialising in Brand/UX/Marketing, then is there really any point in that person being on the team? Can you say that they are putting their expertise to use, or just doing as they are told?

Now let’s turn that user story into a why rather than a what; “As a potential donor, I want to see pictures or features on the page that make me empathize with the cause, so that I want to give more money”. Automatically you have given your Brand/UX/Marketing expert something to put their skill to use with. Rather than a static picture at the top of the page, maybe they have research to show that user generated content or case studies are more effective? Maybe several pictures and quotes throughout the page is more effective than one big picture at the top? By focusing on the what rather than the why, you are missing out on all of these insights and a wealth of experience and knowledge, making use of the people in your team rather than just feeding them work that is so prescriptive that almost anyone could do it.

Delving into the why rather than the what with user stories can be very beneficial, but like all things has its positives and negatives and may not be entirely appropriate for your project. To very basically summarize the information in this article, here are a list of the pro’s and con’s for each:

The What:

Pros:

-         Easier for stakeholders to grasp

-         Great if it is a small project with a very specific vision

Cons:

-         Very narrow; doesn’t allow room for innovation, creativity and expertise

-         Can be difficult to navigate if there are any issues which means the ‘what’ isn’t feasible, such as security or budgetary issues

-         Could prevent a solution which is cheaper, better future proofed, easier, etc., to be found

The Why:

Pros:

-         Makes use of the expertise on your team to come up with better solutions for your stakeholders

-         Easier to be dynamic and react to changes in scope, budget, etc

Cons:

-         Can be more difficult for stakeholders to grasp

-         Need to ensure there is strong acceptance criteria and generally enough detail that the user story isn’t too vague for the Dev team to work on

 The Why Can Be Scary For Your Stakeholders:

The why can be a scary thing for some stakeholders. Whilst some stakeholders may be happy to trust that you know what is best, you will find some that balk at the lack of precision and control that they feel the why necessitates. The what is much more comfortable for them as it gives them something fixed to expect.

I attended a breakfast seminar at a digital conference several months ago being run by a company (which surprisingly didn’t turn out to be a thinly veiled sales pitch) which was focused around how we could become better customers. One of the discussion points they brought up was this concept of the why and the what (although not in those exact terms) and how from their point of view they felt that they were doing their customers a massive disservice when they were just being told to focus on the what. It prevented them from applying their expertise and their insider knowledge of the industry to help build a product which not only met the requirements but was also future-proof and would stay relevant.

I was surprised when a few of the digital project managers in the seminar became extremely defensive over this approach. Their reasonings were that this way of working could quickly become expensive; that it would take too long and they had tight deadlines; and that they didn’t have any idea where their organisation would be in a years’ time so there was no point in focusing on future-proofing.

It’s true that yes, it could turn out more expensive than anticipated, but think about it in the long term; what will be the cost of having to do additional work, upgrades, or having to specify that any new systems you work on in the future have to conform to a narrow set of requirements as set by having this particular system in place?

Same with tight deadlines too; will spending a bit of extra time now actually save you time and resource in the future? Is the tight deadline symptomatic of a larger problem within the organisation you work for and their expectations in general?

Again, with the excuse of not knowing where your organisation will be in a years’ time – is this symptomatic of a larger issue within your organisation in regards to strategy, planning, or communications? If so, these could continue to affect your ability to really utilize the why and get extra out of your products with every project.

This may be a slightly different dynamic than is faced with internal stakeholders (hopefully), as unless you have worked with a supplier for a while there will naturally be a healthy suspicion around whether or not they are genuine, suddenly going to hit you with hidden fees, miss deadlines, etc. With internal stakeholders especially though, it is important to work on ensuring that they trust you to understand and therefore be able to interpret their vision of the product if you want to persuade them that the why has the ability to be much more beneficial in the long term.