Nuance to user stories
The more I learn about user stories and attempt to use them in practice, the more questions I have. I understand that a user story:
- Represents a chunk of functionality that is valuable to an end user.
- Is intended as placeholder for conversation, as shared understanding of requirements cannot be achieved through documentation alone.
The term ‘chunk of functionality’ to me sounds like what many people describe as a feature or epic. This is where things get muddy for me, because the kind of user story I typically see in a sprint backlog would not be described as a feature or epic. I realise a lot of this will be semantics, but it brings me to my first set of questions:
- How would you define the difference between a feature, epic and user story; in the least abstract terms possible? (e.g., is there a litmus test where you could look at a PBI and determine which level it’s at?)
- I think of a user story as being at the same level as a stakeholder requirement from BABOK. The functional requirements that sit below that stakeholder requirement would then be drawn out through conversation (as the story is refined), and would then be documented within the story (in the form of acceptance criteria, supporting information, diagrams etc.). It this a valid way of thinking about it?
- I cannot make sense of user stories outside the context of end user functionality (i.e. a human end user interacting with a system through a UI). The moment people try and shoe horn other kinds of requirements into this format (e.g. as an API, as a developer, as a system) it just becomes too abstract for me and I think it is a slippery slope. What are your thoughts on this?
If we take an example of a customer that wishes to order an item from an eCommerce store. The high-level goal of the customer might be written as:
as a customer, I want to order a product
Whilst this is ultimately the outcome the customer want’s, it’s way too high level to be meaningful to a developer. Would we call this a user story? Or would we call it something different entirely (an epic? a feature?). I certainly wouldn’t expect to see it in a sprint backlog.
Maybe we break it down:
- As a customer I want to find a product
- As a customer I want to add a product to my basket
- As a customer I want to proceed to checkout
- As a customer I want to select my preferred delivery method
- As a customer I want to pay for my order
In terms of the ‘so’ part of these stories, it seems self-evident because these are all requisite steps for the customer to order the product, which is the outcome they want to achieve. Finding a product itself doesn’t deliver any value to the customer unless it enables them to ultimately order that product and get their hands on it.
Furthermore these stories still feel very high level, and feel more like chunks of functionality. Would you still consider them user stories? Or something else?
We could then break them down further… for example if we take the story:
as a customer, I want to find a product
We could break this down into things such as:
- As a customer I want to view a list of all available products
- As a customer I want to search for a product
- As a customer I want to sort the available products by price
- As a customer I want to sort the available products by customer rating
- As a customer I want to filter the available products by brand
- As a customer I want to filter the available products by size
Once again, for these stories it feels as though the ‘so’ part is self-evident because it’s ultimately to help the customer find the right product. It would feel contrived to add that to the end of each story.
I’ve probably laboured this point by now, but you can probably see my confusion around the levels of abstraction. This probably all links back to my initial questions (particularly around the how to differentiate between features, epics, and user stories). I guess what I am struggling with is to know the right size and level of detail of a user story, so that it can go into a sprint backlog and a developer can meaningfully work to implement it.
Any recommendations for where to start to settle my confusions.
User Stories are not mentioned at all in the Scrum Guide. The Guide refers to Product Backlog Items and never says anything about how those items are crafted. Personally, I don't like to utilize User Stories because there is always confusion around how to write them "correctly". I prefer that the Product Backlog Item use whatever format is necessary for the Scrum Team to fully understand the need and expected results.
Now, to answer some of your questions with my opinions. Remember these are my opinions so take them for what you will.
Epics were not included in the original use of User Stories. There were just stories at various level of refinement. The less refined were "larger" but still conveyed the needs. As refinement took place, some of the larger stories were broken down into multiple stories and the larger story no longer was needed. That is my preferred method of using User Stories. As a story is broken down into more actionable stories, the large stories can be deleted. If anything is called an epic, it is usually something that has a 5-10 word description of a high level need. In your case it would say "Customers need the ability to find and purchase products". There would be nothing else stated and that is usually the "heading". It will allow for linking actionable stories to a single item so that visualizing the amount of work done and still to do is easier.
You state that the "so that" is usually obvious. It may be obvious on the larger stories, but as stories are refined into actionable items, the "so that" may not be so obvious, especially if the story is a precursor to another story. The "so that" can be "in order to allow for <XYZ action> to be started/completed" and have nothing to do with the customer's actions/needs.
My advice is not to get too hung up on how to do properly do and use User Stories. Focus instead on how to help the Product Owner manage a list of work that is needed in order to improve the product. Focus on helping the Scrum Team capture the information that is needed for work to satisfy the needs and being capable of satisfying the Definition of Done in a single Sprint. There are many ways to capture the needed information so help the team find what works best for them.
Also, something that is usually a big issue for organizations that use User Stories is how to deal with a defect/bug and how to deal with technical debt. By not requiring everything to be in a specific format, you can have each Product Backlog Item define the need in a way that is understandable and then manage them all the same. Do not distinguish between an updated feature, a new feature, upgrades to infrastructure software versions, or defects. Just see everything as something that is needed in order to improve the Product and order them appropriately.
I guess what I am struggling with is to know the right size and level of detail of a user story, so that it can go into a sprint backlog and a developer can meaningfully work to implement it.
You don't need to know that. The Developers do. They are the ones, after all, who will be doing the work. It would be better to coach them to refine work themselves to the point of it being ready for Sprint Planning, meaning they are satisfied it can be completed within a Sprint. Look up the INVEST criteria and offer that for guidance.
If Developers are scratching their heads in Sprint Planning and are wondering "can we do this work", something has gone wrong. The question ought to be, "Should we? Should we do this work in order to achieve the best Sprint Goal?"
Scrum Guide does not mention user stories, but Scrum Alliance does.
Besides user stories are essential to whole Agile thinking and Agile manifesto
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 actuall USER STORY
Best way to collect user stories is actual costumer 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, no longer then one month long is to release what can be released as early as possible, so the maximum amount of end user feedback can be collected, which should then be inspected and adapted into Product Backlog
While thinking about it please consider 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 manageement 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 .
And, which all its Guides, manifestos, certifications and philosopthy it is a tool which is created within wider business concept, Agile fro very simply and materialistic puprose, 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-like using a car as storage room or as a decoration.
And the whole foundation of Scrum as a money making tool, 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 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
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
For me, epic is just a ticket representation of a larger story that can potentially form a goal of the sprint.
I use the same "As-I want-So that" description to outline the need. I then add some context - like who has requested it, what is an evidence of the value, etc. I can also add some "Given-Then" blocks to outline the possible solution for this need. Then, I add some important acceptance criteria. Developers can then change any or all of the above if they need.
It is convenient to bring a larger story to developers as an epic so that after it is refined to smaller items (like specific use cases or technical tasks), these items could fit nicely as tickets inside epic.
Then, you have a very well documented larger story and a clear break down of this story to smaller items.
But there are other ways to do this same thing, for example the way Daniel has explained.
To Nicholas: Scrum doesn't have better or worse application for profitable or non-profitable organisations. Prince2 is for project management in controlled environment. I would appreciate if someone would show me any controlled environment.
Bureaucratic government hierarchy in the typical government institution , which is receiving fixed salary from taxpayers money is a best example of "controlled environment"
How strong is a control is another story, it can be absolute like in North Korea, or dysfunctional, like in Somalia, but the model itself is a controlled environment, which does not have space or purpose for self managing teams
Another example is a corporate entity with a fixed hierarchy, long term planning, production quotes, system of reward and punishment based on meeting the superior requests and strong chain of command from up to down.
The whole foundation of Agile is based on studying the market success of commercial firms, especially Toyota. Scrum and Agile were created for one sole purpose-to increase profits of the commercial companies. It is explicitly written in all founding documents that only measurement of teams success and only read tape which it has to consider is a VALUE OF THE PRODUCT-which means market value
Product owner, one of the key figures in Scrum team has a sole purpose of successfully selling and marketing the product which dream develops. If the organisation who is sponsoring Scrum does not sell any goods(digital or physical) or services, this role has no purpose, and whole stress of time boxed meetings, the cross functional teams where everyone is responsible for result(which is measures only in Dollars, Euros, Rubles, Yens, bitcoins or gold coins, but not in story points or any other abstract evaluations) and stop-switch sprints too
Private charities who distribute goods and services for free and live of the donations can use Scrum, because they have financial balance sheet too-the success of scrum team will mean receiving more donations, and distributing more goods and services, which can be accounted for in monetary terms
Political parties can use Scrum, in their case product is their platform, and success is measured in the amount of monetary donations, and new members who pay membership fee
But I personally have a hard time understanding for reasons for implementing Scrum in organisations who don't sell anything, directly or at least indirectly, are not competitive and are not in any way dependent on market value of the product and services they release. Or who don't release any product and services.
What can be the purpose of Scrum in a scientific lab who is researching the theoretical aspects of physics? In government ministry?
What will be PO doing-selling micro parcels on the market or maximising the value of services bureaucrats are providing?
It's not written in the manifesto, but it is so self evident from the whole logic of the Scrum theory and practice.
The terminology and language of Scrum has exact, not metaphorical meaning
"Product" is a product, "Evidence based marketing" is an evidence based marketing, value is a financial value
Please don't get me wrong, ANY team can have daily 15 minutes standups, and meet at least once in a month to report to the director of the organisation, then inspect itself for 3 hours, and plan next month.
Any team anywhere can be given autonomy. But this alone does not make it Scrum team.
Because the aspect of value(which is financial value) will be absent, and whole purpose of Product owner(who, is in a simple words a salesman) will be lost
A user story is literally a story told by a user. It describes what work a user needs to do or what goal they need to achieve. That is in stark opposition to describing what the system needs to be able to do.
A feature delivers functionality that enables a user to achieve their goal or perform a task. A feature is what a team delivers and can be the result of one or more user stories.
An epic is a big user story that should be split into smaller ones.
Furthermore these stories still feel very high level, and feel more like chunks of functionality.
That's what it is.
In terms of the ‘so’ part of these stories, it seems self-evident because these are all requisite steps for the customer to order the product
It seems self-evident because, for the most part, they describe the system. As you said yourself, those are rather features (functionality) than user stories. If you already know how a system should look like and what functionality it needs to provide, then there is no point in having user stories in the first place.
"As a customer, I want to find a product" could be a user story, but the breakdown contains features again, and "a" product is far too vague. Incidentally, a "so that" could help here. "so that I can make a bargain", e.g. Sorting by price could then be a feature that helps with that, but so could promoting special offers. What kind of product? The most valuable one? -> user story. Customer rating could help me to find that product -> feature.
it feels as though the ‘so’ part is self-evident because it’s ultimately to help the customer find the right product.
Are those selected features the best way to achieve that? What constitutes as right? See the paragraph above. Not having user stories prevents such useful conversations and the team from coming up with potentially better solutions. The team includes the PO, of course.
As for the right size of stories: The right size for a sprint is determined by the developers. That's what refinements are for. How far the PO should go with splitting in advance is something to find out in an agile way.
Such a lucid explanation @Oliver! Thank you so much. _/\_
@Oliver - I look at the "so that ..." line in a User Story as the why and as help with prioritizing the importance or order in which the work should be delivered.
The whole structure of the user story is: As a <the WHO, user requesting> I want <the WHAT, requirement description of what the user wants>, so that <WHY, reason for the request>.
The WHO and the WHY sections of the user story are key bits of information for prioritizing a requirement.