Allowing development teams to build amazing solutions starts with the “Why” not the “What”. Sure there is acceptance criteria that must be met, but how do you make sure that what is getting built is what is actually needed?
The secret lies within a simple yet powerful shift in focus. Always start with a great "Why" to everything in your development cycle. I could easily say everything in your company, or for that matter, your life but let’s try to save the world one piece of software at a time.
The quickest way to get understanding from everyone is by emphasizing the business value. Why is the feature important? This allows for greater buy-in and flexibility. Focusing on the "Why" allows developers to make the implementation tailored to the business needs. The quality assurance team then can apply the "Why" to what they are testing, further validating and refining the business value.
Most people communicate via “What”. Which is great when communicating what needs to be done, but it can clutter the mind with what and how before getting true buy-in on the feature/idea/story.
Do a search for “user stories” and you will find article after article littered with the “Why” at the end of story. It could be argued that will make the “Why” stick with the reader. In my experience as a crusty old developer, the “Why” becomes noise. As soon as I see the "What", common thoughts tend to form: “They want to do what?” or “Oh, that’s easy, maybe half a day's work.” or “I don’t want to touch that code, I hope <insert other crusty old developer> takes that one.”
Instead, making the “Why” the first thing everyone reads is much more powerful. It allows the reader to latch onto why this feature is so important that they need to put their limited time towards it. It is like an anchor if you will, but not one that stops the ship, but one that… allows everyone to... jump on board… …aborting analogy… backing away.
Anyways, don’t take my words or lack thereof, many have already established this format as their way to work. The original submitter of this idea was Liz Keogh in her article RIP As a… I want… So that…. Also Simon Sinek gave a great TEDx talk about Start with Why, which applies to a much higher level than user stories, but is very applicable to our work.
But how do you get a great why when most people communicate via “What”?
Unless you are the one coming up with the idea, you are extracting information from someone else. More than likely they are only talking about what they want. There is a translation that needs to happen in order to get a solution that at least implements but hopefully exceeds expectations. This translation may not include the original idea based on the real “Why”.
That said, I always start with listening to all the information possible. I want a raw brain dump from those involved before I tried to determine the root problem. Jumping to conclusions and forcing a solution too early may be a horrible idea and possibly the worst you can make.
After the initial brain dump on the idea, it is time to really dive into the dark corners. The pit of despair is waiting for unsuspecting business analysts and product owners to make the slightest misstep. But how do you find these traps?
After digesting the initial idea, seek out the stakeholders involved. This may be the person that gave you the original information or not. The job at this point is to find out the true root of the problem that the idea is trying to solve.
Maybe you can ask them why and they will tell you, but most of the time more digging is involved. One method is the Five Whys. This can be effective depending on the person. It can also be annoying to the person, but that may help them really have to think about their answers.
Another method that I like to use is to ask the stakeholder who will be using this solution and how. This will hopefully get the stakeholder to empathize with the user. Once we are there, I think start asking why that user group would want/need this solution.
This gives me a few points of information. First it lets me know who they think the intended user is. Second it gives me a frame of reference for their perception of the solution for that user group. Third it allows for comparison when talking with a sample from that end user group.
From this line of questioning I may draw my own “Whys”. I then validate these ideas with the stakeholders to see if there is buy-in. Coming out of the stakeholder interviews, there should be a good understanding of the why.
At this point I write some super high level stories without any acceptance criteria that focus on the business value. I include a brief what but try to leave it open ended. The what of the story may have changed from the original request depending on the information gathered. I also do not formalize these in any way. They may be written on sticky notes or in a simple text app so they do not look “official”.
With the loose stories in hand, I doff my stakeholders and seek those whose blood will be spent by these stories. But who do I talk with? I try to include everyone that will be affected by the work that is to be done. This can include these and more:
Once the list of subject matter experts is established, I meet with each group individually. I don’t want to bog everyone down with meetings where they aren’t completely engaged. I also don’t want too much influence from other groups tainting what information can be gleaned.
I do these meetings for three reasons:
During these meetings I give a high level overview of the project. For everyone but the end users, I then talk about the “Why” focused stories. I focus on the three reasons I am having these meetings, checking for blockers and getting buy-in & input.
The end users I handle differently. There are many types of end users. They could be internal people in marketing, finance, warehousing, etc. They could be external like business customers, vendors, the public, etc.
Once I am able to determine which end users to talk with, I ask similar questions to what I asked the stakeholders. What is the current problem they are facing related to this work? How does it affect them? How are they working around it? I avoid asking questions related to what they think should be done. Some of them give that information, but it doesn’t always line up with what is the best solution. I am much more focused on determining what they perceive the root issue is. I then compare this to what the stakeholders thought.
From here I have a pretty good idea of the “Why” and business value. I then build out more official stories which usually include a rough design depending on the project. I present the stories to the Stakeholders to get buy-in. At this point I expect glorious praises or gasps of horror especially if the “What” of the stories is not expected or has changed. I focus on explaining the “Why” or business value and discuss how the “What” is best solving it.
If the stakeholders do not agree with the direction, I would much rather figure that out now before we are days, weeks, or even months down the road. Usually not everything is 100% spot on, so I take input and adjust.
I repeat this process of developing stories and presenting until things get accepted or until I get fired. The getting fired thing hasn’t happened yet, but I keep pushing that boundary to get to the best solutions that we can build.
Wicked smart people say “Why” is important, RIP As a… I want… So that…, Start with Why, you should listen to them. Write stories with the “Why” first:
Interrogate stakeholders and subject matter experts until they give up the “Why” of the problem/request. Create great stories based on the “Why” that enable the team to build amazing solutions that delight everyone!
Are you ready to build something brilliant? We're ready to help.
.jpg)
