Have you ever thought of what a user would do with your application?
No matter how well-architectured the app you built is, if it brings no value ...
For further actions, you may consider blocking this person and/or reporting abuse
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 src.illumos.org/source/history/ill.... 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 OpenSolaris.org) 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.
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!
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?
Yeah, Product Backlog Items are different from user stories. Not all issues are featured related (also not user stories).
As a change consultant, I help organizations through what I will refer to as "agile transformations." My experience in writing user stories like those proposed in this article is excellent for framing the requirement, putting yourself in the right frame of mind, and bringing consistency to the planning process.
How exactly you write the user story (or requirement) does not always have to follow the exact word-for-word writing that this article proposes. Keeping the who, what, why, value and definition as a mental template is super helpful.
For example, I recently had a senior person wanting to build a bunch of new reports. They were spending a lot of unbudgeted money to drive new potential customers to their trade show (they had too many existing customers and wanted to onboard more customers). They requested new reports, changes to how we manage all our customer data, and potentially purchasing some new software that could help track all of this.
Their requirements spread across multiple teams with different requests and a lack of a cohesive strategy. The leader was trying to make things happen because they were taking a significant risk and wanted to measure the value of this big new budget spend. However, how the requirements were communicated, it would have taken multiple teams many months to complete. We took this as a training opportunity.
After asking some questions and thinking through the process, we already had all the systems in place; they just didn't know it. We mocked up the request in the form of a few reports, and they said, "Yes! That is what I want!". We took a multi-month effort and brought it down to two dashboard reports with a few minor modifications to the marketing software we used. The entire request took two weeks to complete, with a few minor bug fixes the following two weeks.
We walked the executive through the user story, which looks something like this:
As the lead for our big trade event, I require metrics that prove our planned X, Y, and Z marketing efforts has increased the number of new potential customers over existing customers.
The title of the Jira ticket had a label like this:
"New vs. existing customer differential dashboards"
The ticket details included a copy/paste of the leader's original user story. However, the ticket had more detail, such as assumed systems impacted, databases to access, and teams likely impacted. That additional detail was maybe a page long so the team could understand how we translated the requirement into something useful for engineering and report writers.
By demonstrating how to think about the request and share our process through a simple user story format, the leader better understood how to communicate with these select teams. Now, that leader understands the process, writes down their requests in the style of a user story, and then meets with the product owner to work out the details and the value.
Thank you for sharing your experiences!
I do agree that the format helps other people be on the same page with the team. It can also make it easier to communicate and understand a specific requirement for non-technical people.
Nice... can you add 3C?
Oh, sure! Something like a "The 3 C’s (Card, Conversation, Confirmation) of User Stories" section.
Thank you for the suggestion!
I added 3Cs of User Stories just now!
Not a huge fan of "user stories", since I tend not to work on the types of projects that benefit from that sort of approach, but very nice article nonetheless 😀
Thank you!
Would you mind sharing with me what qualifies as projects that do not benefit much from user stories?
Thing that come to mind are personal projects made for your own self, and projects that have a very limited userbase.
I'm actually really curious, because I can't find any results wherever I look and most content that I see just give users stories too much praise.
It would be nice to know more about case scenarios in which they don't really work well for a project.
The closest I've ever seen to what you're talking about is covered in this article.
Mostly smaller internal projects that are used almost exclusively by coworkers that would rather just call one of the developers directly than opening an issue somewhere.
There's simply less of a need to write down user stories when you can simply sit down with your users and brain-storm how to best solve their problems.
But the small personal projects are obviously another good example.
Most of the stuff I do in my free time isn't meant for end-users anyway though, so user-stories wouldn't make any sense there.
Thank you for sharing your insight!
I guess as a solo freelance developer I didn't really think about those cases.
Building applications to be used by fellow developers or other technical coworkers in the same company may not necessarily need user stories.