The trickiest part of being a developer is getting the client to describe their problem instead of their perceived solution.— Chris Cummer (@senorprogrammer) May 2, 2012
I couldn’t agree with this tweet more. I can’t count the number of times someone’s come up to me and said “we need this”. Not, “we have this problem” or “what do you think of this solution”, it’s “we’ve already picked a solution, you just have to implement it now”.
As a software developer, an integral part of my job (and, honestly, my favorite part) is to analyse someone’s problem and offer digital solutions to it. I’ve been doing this for years now, and I feel have got pretty good at it. So when someone comes to me with a solution instead of a problem, I immediately have to question them.
The most important part of a user story to me is the “why”. “As a (user), I want to (do something), so I can (solve a problem)”. This gives the context of the story, the end goal, the actual purpose of the feature / software that you’re writing. Without this, you’re writing blind. You have absolutely no idea if what you’re writing will address the user’s problem.
So when someone comes to me with statements like “We need an API” or “We need to implement this software package”, I immediately ask “Why?”. And then I start the process of helping them understand what their actual problem is. Sometimes end-users are so wrapped up in their own hand-picked solution that they don’t even realize that it’s not addressing their problem. Or sometimes they’ve picked a perfect solution to their problem – but if I don’t know what the original problem is the odds of me implementing it in a satisfactory way are pretty slim.
I am a professional software developer. My teammates are professional business analysts and software developers. We fix problems for a living. So if you have a problem, let me find a solution for you – that’s what you’re paying me for.