DEV Community

Discussion on: The Art of Writing Agile User Stories

jmcp profile image
James McPherson

I've been a software engineer for 25y, and the "user story" way of describing requests-for-enhancements drives me up the wall.

For example, perhaps you identify that a particular component of an application is performing poorly, and that this can be improved. Why why should you have to write this as

"As a user of applicationX, I want componentY to perform better"

rather than

"componentY performs poorly when {condition summary} is {true or false}"

What is relevant here is that some aspect of the product/application/utility performs poorly under certain conditions - and who you are is irrelevant to that.

Or perhaps you want to add a new feature?

"As a user of applicationX, I want there to be a componentY"

As you allude to in the discussion, this doesn't give any idea of what is really needed, why it is needed, or concerns that might go in to designing and engineering a good solution.

Here's a synopsis that I wrote (and delivered the code to make it happen):

$bugid fwflash should be generic and pluggable

which you can see at fwflash is the Solaris firmware flashing utility.

That synopsis doesn't depend on any particular person's existence or involvement and describes at a high level what is needed. The RFE text (sadly, no longer available after Oracle shut down explained that

1- the existing tool was tightly coupled to one specific brand of device
2- the existing tool was not extensible to any new devices - even those from the manufacturer in #1, and
3- by solving #1 and #2 we could greatly improve the customer experience for all the flashable devices that Sun made and sold.

I could, I suppose, have written

As a user, I want to be able to flash/upgrade the firmware on any device sold by Sun

(and added a modifier like "easily") - but what does that actually add to our understanding of what is needed? Nothing, in my opinion.

By all means, if a particular user's identity or attributes is relevant, mention that. In my experience that is very rarely the case so I am firmly of the opinion that "as a [..]" should be excised.

aminmansuri profile image

As I understand it a User Story is for future features.

If you're saying "component X performs poorly" isn't that a Bug rather than a "user story"?

Our general practice is to schedule issues. Some issues may be future features (that could be expressed as "user stories") or it could be bugs that we need to fix (that are best expressed in the direct "component X doesn't work").

Or am I missing somehting?

rammina profile image
Rammina Author

Yeah, Product Backlog Items are different from user stories. Not all issues are featured related (also not user stories).

rammina profile image
Rammina Author

You bring up a good point. Following the typical format of
As a(n) ... I want to ... so I can...
is not mandatory in Agile and Scrum anyway.

Following that template does not guarantee a quality user story either. And in some cases, it is way too limiting or "stiff" to use when describing a requirement or need. In those cases, it might be better to just not follow the typical format or one could just create a Product Backlog Item instead.

I tend to think of the template as "training wheels" for Agile/Scrum teams who are new to writing user stories. That said, User Stories do not necessarily have to be in this format, but it guides the story writer into expressing those three important questions.

Thank you for sharing your insights!