User stories are not implementation specifications. They should not encapsulate pixel-perfect designs or detail specific fields on a given interface.
They should not shackle the technical team with unnecessarily rigid and unforgiving acceptance criteria.
Nothing is more depressing than picking up a user story where a well-meaning, non-technical person has tried to define every aspect of the implementation.
When I worked as a developer, I found this practice discouraged a sense of ownership over the solution.
Software requirements is a communication problem
Mike Cohn, “User stories explained”
User stories 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, implications, etc., as they become known through conversations and refinement.
But exercise caution if going much further than that. Supporting assets like high-fidelity prototypes and enduring technical documentation are best placed outside the user story.
Allow your technical team the opportunity to do what they know best and leave the โhowโ out of your user stories.
If you are unhappy with your development team, they may need more detailed guidance.
Better software requirements can help with this.
|
Frank Ray Consulting. Software requirements for agile development teams, particularly remote, outsourced and offshore development teams working in financial services. |