This article talks about a different approach to capturing product requirements and describing the problems a team is trying to solve. It describes user story as too limiting, perhaps too granular. The story loses the meat of the problem being solved and the setting in which it is being solved. The author proposes a new story format called a job story. A job story intends to capture more context around the user, their needs, and how they’re interacting with the software.
This kind of challenge to the user story format is not new – nobody enjoys writing user stories because they’re fairly artificial, often too obvious, and it can feel less than valuable. The solution certainly addresses aspects of the challenge, but I see the author’s suggestion as overly blunt. A key part of the agile manifesto for me, is as follows
I was in a fairly stressful meeting a couple of weeks back and to break the tension someone put up a YouTube video. The meeting room had a few very smart and talented engineers in it, one of which put the video up for laughs. Here’s the video – go ahead and watch it if you haven’t already. You don’t have to sit through the entire thing, the first minute is enough.
So put aside the fact that their marriage isn’t going to last (because the husband obviously has very little regard for his wife). Put aside the fact that you’re probably boggled at the idea that the question wasn’t easy to answer. Take a closer look at what’s going on for the girl struggling to answer the question. She keeps going back to a frame of reference she’s familiar with in trying to answer the question.
She has a very obvious frame of reference or, in some ways a mental model, of how to think about speed and distance. It is entirely based on how fast she can run.
I’m not going to say that I didn’t smile when I first saw the video, but after a minute or so of watching her struggle I started to try to understand how she was approaching the problem. I like to think this was the user-centric analyst in me. She has a problem she is trying to solve and she has a very strong mental model that she is trying to use to solve that problem. I’m not going to say that we need to design software for this particular mental model. What I am going to say is that we, as software designers, engineers, and producers, should never guess at a user’s mental model. Sometimes their frame of reference turns out to be laughable in our minds. However if we can tap into it and understand it, then the solutions we design will be so, so much the better for our efforts.
So giggle if you must, but take this as a cautionary tale – sometimes a user’s mental model is extremely unexpected. The best way to understand our users is to go meet with them and watch them do work. Don’t assume you know how they think.
I was reviewing a wireframe of mine the other day with my team and we felt a little stumped by one particular part of the design. It felt like it was a good design but I couldn’t put into words why I preferred it over the alternate I had proposed. The team also struggled with giving a name to why it was a better design – until our newest member spoke up.
