Developers decide the implementation

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. And also that you can write it down in a completely unambiguous way.

Even if you have the ability to possibly define precisely how something should work, spare a thought for the poor developer on the receiving end. 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 also creating 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. It should be implemented according to the design system already in use 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.