User stories are not meant to be implementation specifications. They are not meant to encapsulate pixel-perfect designs or detail specific fields on a given interface.
They are not meant to shackle the technical team through rigid and unforgiving acceptance criteria.
There is nothing more depressing than picking up a user story where a well-meaning non-techie has tried to define every aspect of the implementation.
When I worked as a developer, I found this practice discouraged me from asking questions and prevented a sense of “ownership” over the solution.
Software requirements is a communication problem
Mike Cohn, “User stories explained”
Instead, user stories are intended to help solve the communication problem between the business (who needs something) and the technical team (who builds something).
There is nothing wrong with narrating the story card with technical details and implications etc as they become known through conversations and refinement, rather this is often quite useful for the technical team.
But I caution you from going much further than that. Additionally, high-fidelity prototypes and enduring technical documentation is usually best placed located outside of the user story anyhow.
So give your technical team the opportunity to do what they know best and leave the “how” out of your user stories.
Frank Ray Consulting. Software requirements for agile development teams, particularly distributed, remote and offshore development teams working in financial services.
Get in touch if you need our help