How to make up good user stories
How to make up good user stories?
Best advice-don't make them up. Scrum is a business tool, not the scientific research, religion or ideology.
And in business, generally, there is a good rule-if you are trying to run your business out of your head, you are dead.
Business is only good when it is based on the proper understanding of what people are ready to spend their money for, and why.
That's we core of Agile mentality by the way
Please let me elaborate.
First of all there is a question if Scrum team needs user stories at all?
Scrum Guide does not mention user stories, but Scrum Alliance does.
Besides user stories are essential to whole Agile thinking and Agile manifesto. Let me quote please:
"Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan"
Customer collaboration can take other forms but user stories are proven to be most useful so far.
Scrum is a part of Agile, and as long as it stays so, the user stories have the fundamental meaning for Scrum projects
But please try your best not to work on user stories out of your head.
One of the interesting things about Scrum is that things are mostly called WHAT THEY ARE
Road map is a road map, impediment is impediment, team is a team, and eventually user story is actual USER STORY
Best way to collect user stories is actual customer collaboration, which is a task for PO, but also to the whole Scrum team
One of the logics why Scrum is divided into small "stop - start" sprints, which as we know shouldn't be longer then one month, is to release what can be released as early as possible... So the maximum amount of end user feedback can be collected early, which should then be inspected and adapted into Product Backlog
While thinking about it please consider, once again, that Scrum is not a scientific theory or a religion which exists for its own sake.
You may call it "framework" like Scrum Guide does, or brake a rule and call it project management methodology(like every company calls it anyway in its reports) but the main thing is that Scrum is a TOOL, not the MATTER, ISSUE or BELIEF.
And, which all its Guides, manifestos, certifications and philosophy it is a tool which is created within a wider business concept. Scrum is a part of Agile and exists for very simple and materialistic purpose. To make profits.
One can use Scrum as a hobby, for research or for other reasons of course, but it will be use unrelated purposes then. Like using a car as storage room or as a decoration.
And the whole foundation of Scrum as a money making tool, and as the Agile methodology, is based on core principe of building and changing a product around customer feedback.
So this makes the whole issue "how to write/make good user stories" obsolete
Dont make them up. If you don't have any customer feedback about the product you are selling make up as little as necessary for a first impediment, release it as early as possible, make sure you have tools to collect maximum amount of end user feedback, collect as much end user feedback as possible, and start adapting the product goal and backlog according to the collected USER STORIES
Brake the complicated ones(epics) into shorter ones, edit the complicated language in such way that developers understand it, and have your Product backlog full of user stories without making anything up.
And if you are NOT SELLING any product, then think twice if you need Scrum at all, and why.
There is wonderful methodology developed by UK government for the government projects, non profits and other entities who aren't primarily based on on profit.
It is called PRINCE2 focused achieving the planned result, not on increasing the value of the sold products and services, and might be more suitable.
Remember that Scrum isn't a silver bullet for all your problems, it is just a tool which has to be used in a certain circumstances, for certain purpose.
Using Scrum in non profit organizations is often like having sales and marketing department in the charity organization Both ideas might work, but only once in a while
Thank you for your detailed explanation. I completely agree that user stories should not be made up out of thin air. It is crucial to collect customer feedback and collaborate with them to understand their needs and wants before creating user stories. As you mentioned, Scrum is a tool that is based on the Agile principle of customer collaboration, and user stories are a way to capture customer needs and requirements. Breaking down epics into smaller user stories and using clear language will make them easier for developers to understand and implement. And it's important to remember that while Scrum is a powerful tool, it may not be the best fit for every organization or project, and alternative methodologies like PRINCE2 may be more suitable for non-profit or government projects. Thank you for sharing your insights!
Not sure if the point / question is user story or scrum in general.
If it's user story, then here are my two cents.
User story is just a means to express what's the expected value to be delivered.
As long as teams can achieve it by any other means be explaining the expectation verbally or calling them a product backlog item, and having an unambiguous requirement, you are good to not "make up" user story and still practice scrum.
Remember, the scrum is a means to an end of achieving consistent value delivery , and not the end itself.
I hope I made sense.
Not having any user stories at all would still fit project in a framework of Scrum but in many ways would deviate from what is clear common sense of whole Agile thinking-customer collaboration.
Please lets remember that Scrum is part of Agile and hence also fits into Agile manifesto, which makes customer collaboration quiote clear, and hence justifies use of interactive user stories.
Additionally to that Scrum includes Evidence Based Management which more clearly prescribes need of customer feedback.
It is also quite obvious that once customer feedback is received , it should reflect itself in the Product backlog somehow.
Not having any user stories at all would still fit project in a framework of Scrum but in many ways would deviate from what is clear common sense of whole Agile thinking-customer collaboration.
user story is just one of the many ways which can tell "who{user} gets benefitted and how{value}"
As long as the team can understand it through any of the senses of sight , sound or vision , theoretically they can produce the required value.
I am currently serving a team, where we don't follow the traditional "as a {user}, i ...., so that ...." format, but the customer conveys and aligns what are the expected functionalities upfront. Additionally, the end-users frequently have screen sharing sessions and discussions with the team to give the feedback on work-in-progress, which allows us to adjust as they need almost instantaneously. {Can it get any better? :)} of course, we get a formal sign-off, and document the whole process in in a tool, which can be easily understood by anyone in present or in future. But that's secondary.
Point being, yes, user story is a time-tested way to achieve just one part of the whole collaboration process, which is aligning on what does customer needs and what is the expected value. Taking/ "feedback" on the developed product can have other effective ways as well.
Which one depends on team's constraints.