Good developers value the freedom to decide how best to implement the stories they are working on. They love the time and means to evaluate different solutions, before making a choice and proceeding with implementation.
More junior developers may need help to evaluate the solution options, and company processes may dictate a ‘sign-off’ on architectural decisions.
However, what these developers most need is a clear and unambiguous understanding of what should be achieved as an outcome of their 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.
Developers need to be exposed to enough business context to be helpful but not so much that it becomes overwhelming or a hindrance to 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 there is so much ambiguity here that further clarification will absolutely be required.
Here is what I’d ask the business stakeholder to clarify 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 user contact details ever be shared with third-party agencies? Does the legal department need to be involved in this story? etc
Once answers are forthcoming, the user story is updated accordingly and also potentially split into several other stories.
We are now getting closer to the first developer conversation, but as a technical BA, 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 have to waste time discovering it for themselves.
None of this dictates how the developer should do the work; instead, it should be an incredibly helpful starting point.
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