There is a very common interaction that I’ve seen repeated in pretty much every project in every company I have ever worked for. It’s when a tester logs a bug and the developer argues that, actually, it’s working how it is supposed to work.
The result of this is often a passive aggressive email chain with half the department CC’d in, eventually being resolved by a product manager/owner who gets the privilege of deciding who gets to walk around with smug-face for the rest of the day.
Luckily this has never happened at Surevine, because we use Slack instead of email to communicate our passive aggression and smugness.
That’s a joke…mostly.
So how do we avoid this problem? The simplest answer is ‘better communication’, the better answer is ‘earlier communication’, and in this case the more targeted answer is ‘user story analysis’.
User story analysis (or USA for short…actually I think that one’s already taken) is where you get together the product owner, developer and tester together to discuss a user story (or requirement) before any of the code has been written for that functionality.
It’s important that all three of these are represented for a couple reasons. The first is the more obvious, that the three functions should all be represented and involved in the discussion so that they’re on the same page. The second is that with three people you are much less likely to suffer from shared assumption or biases.
Who leads the session isn’t particularly important, but it’s key that whoever leads it makes sure that the session doesn’t end until there is a shared expectation and an agreed outcome.
That agreed outcome for us is in the form of acceptance criteria, but it could be in refined requirements, notes, or just some bullet points stuck against a ticket in Jira. As long as it’s clear and concise and everyone agrees, you’re doing alright.
The outcome of doing this is that the discussions that often end up being drawn-out arguments and bug reports further down the line become brief chats with positive outcomes. The whole team are on the same page, assumptions and biases have been addresses, and generally speaking the development goes much smoother.
In my experience also, they’re quite enjoyable. When you talk about these things later on in the process, you’ve already hamstrung yourself with tech and approach decisions. When you discuss it earlier, there is much more freedom and many more options available to explore.
The greatest benefit though, and the one that’ll get it implemented fastest, is that quite simply is saves time and money. Fixing bugs and changing functionality is a costly exercise, whereas a half-hour chat is cheap.
It should also reduce the little number by the side of your inbox. It’s worth it for that alone, surely?