First, the lingo…
Every industry has short-hand terms to refer quickly to complicated things and ideas. Software development is no exception, so a few definitions before we get started (for more, see Mike Cohn’s writings):
- User story = something the user wants eg I want to download my air quality data into csv
- EPIC = a big user story, eg I want to manage air quality data
- Feature = a collection of user stories that work together, eg I want to see an interactive table of my air quality data (some people, Mike Cohn included, call these Themes)
- Ticket = a individual piece of coding work
- Board = how software development work is management (see Trello as one example)
The scenario
You’ve listened, engaged and researched. You’ve got your client and industry requirements nailed, and broken down into some lovely prioritised EPICs. You’ve then taken these EPICs and broken down into a logical series of features. Within those features you have beautifully written User Stories, with detailed testing requirements and have worked closely with creative colleagues to ensure accompanying UI designs. You have the sign-off of dev team, clarified and rewritten your tickets as required. Each ticket moves across the board, and gets deployed to be tested…
The issue
“This isn’t what I asked for”. Often (in fact almost always, annoyingly so) it will be very close, but that final thing will have been missed or changed whilst in development. Something that went without saying from your non-developer perspective. For example, no logic applied to a list, perhaps an inconsistent design choice or a functioning but slightly illogical workflow.
What should you do?
Firstly, keep it nice and cool. The issue here is the difference between how you imagined that new feature, versus how it manifested. You are an invested individual with emotional skin in the game. Think of the time you went to go see that new film of an old book you loved, and it simply wasn’t what you imagined (Hitchhiker’s guide to the galaxy anyone…?). Software development is iterative, cyclical and ongoing; it’s really important to take it all in your stride.
Secondly, spin out the issue. Create a separate ticket, put it on the prioritised to do list (aka the backlog) and keep the wheels turning. Yes, the temptation is to say no, unacceptable, do it again. However, this acts as a conflict between product, design and development and should be avoided unless it is truly a game-stopping issue. Furthermore, passing a ticket twice across the board is grossly inefficient, think about if a car had to pass along the manufacturing line twice before being ready for sale.
Finally, look and see what you can change in your tickets. Upgrade the detail; get to the root cause. Alternatively, work closer with your dev team. See it as a creative partnership between a writer and director; the mutual understanding and trust will produce far greater work than a standard functioning-only relationship. Open informal conversations, ensure the product development cycle enables formal points for shyer colleagues, and simply get to know your team better. If they informally understand your perspective and what matters to you, they will proactively suggest and therefore pre-empt issues.
So… Just Keep Spinning.
Make peace that tickets will occasionally be delivered with unexpected quirks. Keep it cool, spin out the issue into a separate prioritised ticket and plan so this specific point doesn’t happen again.
