That was a hotly debated topic I posted on a LinkedIn poll. The poll received 2215 views and 29 votes from mostly software professionals, and when closed, revealed a hung jury.
59% of people thought ‘Yes’, and 41% thought ‘No’.
At first glance, it would be easy to conclude that the industry was clearly divided.
However, not being fully satisfied with the poll outcome, I decided to dig into the poll comments to see what they may reveal.
There was a strong consensus that user stories were software requirements and/or had a firm place in the requirements engineering process:
“User functionality should be captured like this”
“I would say it’s a functional requirement from the business”
“It’s a requirement stating what functionality is desired from the system”
“Your example is a sufficient starting point”
“Yes, a way.. but definitely not the only way”
However, many of these comments were caveated with remarks that user stories weren’t enough by themselves, and subsequent implementation details still needed to be worked out:
“They miss, for example, critical details concerning how a solution should be implemented”
“There’s a lot of exploration of various details needed to complete the implementation”
“It’s up to the architect to work out how to implement it”
“Devs decompose it into tasks/requirements”
I came to see that many of the ‘No’ responses were probably more accurately represented as “Yes, but…”.
My bad for a poorly designed survey which would have benefited from a third poll option.
An unexpected, yet incredibly interesting theme to emerge in the comments was regarding the actual usefulness of the user story format, ie. ‘As a user… I want… So that…’. Specifically:
“That template serves as a reminder what to think about when talking to users and that there are different users was well“, but also “I find templates tend to stop people thinking about what really matters and focusing more on how to fill in the template”.
Perhaps most aptly conveyed, “Who would speak like that anyway”.
Quite true. Spend more time on the actual requirements work than polishing the story format.
Are user stories software requirements?
Yes, I believe they are. At least one (of many) forms of requirements. But it’s also clear user stories lack sufficient detail to implement.
One sentence from the poll comments probably best summarises it, which I paraphrase:
“They [user stories] are a placeholder for a conversation with the people who know about the [implementation] details.“
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. |