Good user stories save time

Developers value the freedom to decide how best to implement the stories they are working on. They love having the time to evaluate different solutions, before making a choice and proceeding with the work.

Whilst some developers are also suited to getting involved in clarifying ‘the what’ with business stakeholders, most really aren’t. Most developers just want to build something and learn new stuff as they go.

What these developers most need is a clear and unambiguous understanding of what should be achieved as an outcome of their work.

Enough context should be provided, but not so much that it becomes overwhelming or hinders effective solutioning. This is what a well-defined user story attempts to do.

It’s sometimes more art than science, so perhaps an example is called for.

“I want to solicit the marketing preferences from a user at the time of registering a new account”

A simple one-line goal which may be tempting to pass directly to a developer, but so much ambiguity requires further clarification.

Here is what I’d ask before wasting the developer’s time:

Are there different marketing channels, and if so, will each channel require a separate consent? Can users change their preferences after registering? Is there a time period the consent lasts for? Will explanatory text need to be displayed on the website? Does the text need to be localised? Do you need to solicit preferences from existing users as well? Will contact details ever be shared with third parties? Does the legal department need to be involved in this story?

Once answers are forthcoming, the user story is updated and perhaps also split into several other stories. We are now getting closer to the first developer conversation.

I’d also want to gather an initial impression of existing systems and capabilities relevant to the story, along with details of any strategic initiatives, just so the developer doesn’t need to spend time finding these out.

None of this dictates how the developer should do the work; rather, it should be an incredibly helpful starting point.

If you are unhappy with your development team, they may need more detailed guidance.

Better software requirements can help with this.