Trying to write implementation-ready user stories is a complete losers game. The whole endeavour is premised on the idea that you can define every single aspect of a solution ahead of time. Also that you can write it down in a completely unambiguous way.
Even if you have the ability to define precisely how something should work, spare a thought for the poor developer on the receiving end of this. You are taking away their ability to think for themselves and sending the message that you know more about their work than they do.
Telling the developers what to do because you think it will be quicker is also short-sighted and almost always yields the opposite result. You really don’t want to create a disempowered and demotivated development team, while making a rod for your own back in doing so.
Let’s take the most trivial example: adding a combo box to a screen. Where should it be located? Will it be a fixed width or scale when the window is resized? Does it have a min or max width constraint? Should an option be pre-selected or left blank? Should the text be localised? Does a message need to show if not selected?
Don’t try and answer all this upfront, unhelpfully stuffing your solution into the user story. Just explain to the developer that the user needs to make a selection when completing an existing journey. Implement it according to the design system already used and any other relevant industry best practices.
Ask for an early preview when something is provisionally working and decide what, if anything, is required. Treat changes more like a snag list rather than new user stories, bulleting them out with the developer. You’ll find this to be a much better approach to take.
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. |