Weeks of work results in wireframes, user flows, data models, system specifications. And then, as the team starts to shift from pure design to delivery, out come the post-it notes or the JIRA board. All these requirements get turned into brief statements that are shuffled around on boards until something gets “shipped”. These are the “user stories” that have become the de facto standard for defining requirements on agile projects.
Which is great.
I’ve lost count of the number of times I’ve been asked to confirm how user stories link together, or it’s pointed out ref XYZ doesn’t fit properly with user story HRP. In the worst cases there’s almost a sense of glee that the business has been “caught out” by the superior intellect of the developer.
User stories aren’t the whole of the design
User stories don’t exist in isolation. They coexist with all the design documents and it’s incumbent on designer, product owner and developers to work together to translate the weeks of work into living, breathing products. It isn’t about whether the post-it or the process flow is right and you’re blocked until [fold arms] “someone makes their mind up”. Nor is it about writing “as a, I want to, so that” statements to the nth degree of detail in a pseudo functional specification.
It’s about a team working together to bring a design to life. It’s about a conversation between designers, product owners and developers. It’s about mutual respect and understanding that communication is rarely precise.
So if there’s much rolling of eyes when developers ask questions or huffing and puffing that requirements aren’t clear I’d suggest you stop look at user stories as the problem/solution/focus. You’ve got a bigger problem with how your team’s working together.
Originally posted on my BeBee account.