If you have ever been in contact with a development team in the past 20 years or so, chances are that you’ve heard about User Stories quite a lot. Agile teams all over the world have embraced this concept, especially when using the Scrum framework. Developers, testers and designers are all relying on well written User Stories as snippets of requirements and documentation setting clear expectations and defining the shortest road to success. Not just their own, individual, professional success, but the success of the products they’re working on.

In this article we will look at what User Stories are and how we can work with them so that they enable us to convert our backlog into an amazing product. Of course, this relies on having an effective, efficient and creative development team, working as a well greased backlog consuming value delivery system.

The purpose of this article is by no means to clarify all concepts and the entire terminology associated with Scrum & Agile, but rather focus on this particular area: writing User Stories.

User Stories are probably the most important artefacts of the Agile methodology and the Scrum framework, as any team that applies even some elements of Scrum instead of the full framework (also known as “Scrum But” – eg. We’re doing Scrum, but we’re not doing that retrospective thing… ) are definitely using User Stories to define their requirements.

The explanation for this is quite simple: it will be natural for any team to fight change when it comes to process and way of doing things, but when it comes to adding more clarity and simplicity to the requirements, anyone would go “where do I sign up”. In my 14+ years of experience with Agile & Scrum in various teams and organisations, introducing User Stories was always the easiest step towards the Agile mindset we were trying to achieve.

What is actually a User Story?

As I mentioned before, User Stories are snippets of requirements / specifications, in the context of Agile teams using Scrum (or other) framework. It is just a snippet of the requirements because it focuses on one thing only: the outcome a specific user is trying to achieve when using a specific feature of our application.

The obvious question would be then: how are User Stories different from normal requirements? The answer to this question will become obvious if we look at how requirements are usually written. Frequently, any product requirements document gets into tons of details about many areas, explaining what the user will have to do in order to achieve a certain desirable outcome. So any feature can be summarised as:

As a <User> I want to do <Action> so that <Outcome>.

In this example the User can be a so-called Persona, a role, a user type or any other name you might use in order to be able to categorise your users.

The actual format could be widely different, but the gist of it is the same. The persons writing the requirements are perfectly understanding their users, and they will define exactly what they want and how their users will achieve that.

There is a tiny little problem with that approach: In 25 years of software development I haven’t come across a single person able to articulate that and continue to believe that all the way to the product’s completion. No matter how smart we are, how well we believe we understand a specific domain and how much our guts are telling us that “we got it, we know our users”, reality will quickly kick us in the face and show us that real users might have different expectations. Therefore, focusing just on the outcome, a perfectly good and valid approach many years ago is no longer valid today (and it hasn’t been valid for many years already).

However, there is nothing “inherently” wrong with the above. If we’re able to define any requirement at least in this shape and form, chances are that our product will get a shot at being successful. This way of articulating requirements is still allowing us to build a product that will get at least some of the features right. The entire IT industry has been releasing products using a similar approach for ages, so what can go wrong. Well, many things can go wrong. The world evolved and our customers evolved with it. And their expectations. They expect better products than what you offered yesterday and what your competitors offer. They expect new features to be released often and to wow them on every occasion you have. They expect you to innovate and be ahead of the game.

How can you achieve that? What has anything to do with User Stories?

Well, it has! A lot!

To clarify why, ask yourself this: what is more important? The problem, or the solution?

At this point, I really hope your answer was about the problem. Understanding the problem is key in creating products that customers love. The solution has to change as the problem evolves, because the other way around will never happen. If the users are not satisfied with the solution, they will leave, but not because the solution is not the most amazing ever, but because you ignored them. You ignored their needs. You ignored their problem.

Therefore, what’s the point of writing requirements focused on the solution, when you should be writing them around the actual problem?

So how could we improve the way we write those requirements? We just need to do one thing. Replace the action we would expect our users to do with the reason why they would actually do it.

As a <User> I want <Outcome> so that <Reason/Purpose>.

Hard to see the difference? Let’s fix that with a basic example.

Let’s say your application will require some sort of authentication to allow users to use the app. In most traditional requirements, you would see something like:

As an anonymous (not authenticated) user I would like to be able to enter my user and password so that I can login into the application.

This example, while looking almost like a User Story, it’s not. The focus is not on the WHY, but rather on the HOW. In reality you could expect 2-3 pages of requirements about the details and expectations regarding the login form and various credentials & restrictions, while the core, the gist of the problem would be missing. Why would the user even need a login?

Changing this to an actual User Story would translate the above into:

As an anonymous (not authenticated) user I would like to be authenticated so that I can use the application features securely.

The differences might be subtle, but let’s analyse them:

• The 1st form focuses on what we want the user to do and less on the user’s expectations / needs, even if those are sometimes not functional (or less functional). This is extremely important, as our solutions are not just shipping features, they are supposed to generate the right emotions / feelings to our users (including the feeling of safety and privacy in this case).
• The 2nd form, while keeping an eye on the outcome, places the user front and centre and is focused on the user’s reason for using that particular feature, in this case the feeling of privacy and security.

Beyond these differences, we can immediately see some benefits in using the right form, in phrasing the User Stories with the right focus-points in mind: User, Outcome and Purpose / Reason:

• When User Stories are properly articulated, these very simple headlines communicate a lot to those that design, implement and test them, ensuring that the core values are being followed, and the details are optimised around those values and an efficient delivery.
• When the WHY (the purpose) is clear but the HOW is open, a creative team can come up with solutions that were nowhere on the horizon when the original requirements were built, especially in complex and longer term projects. This is how Agile truly works and this is how innovation is created: putting the minds of creative people together, figuring out how to better solve the user’s problem, not just how to implement the eventual solution in the most effective way.
• Even if the details will change as the time passes, what is truly important regarding this User Story will stay the same. So there is no way we’ll somehow end up missing what’s really important for the user in a pile of details specific to implementation and specifics of the solution rather than the problem.

While all the above is just about naming the user stories, a fairly simple concept, many teams and product owners are failing at properly naming their stories and we will often see backlogs filled with simple statements such as “Implement X feature”. Of course, they add all the details into the descriptions (at least ideally), but that makes it really hard to get the quick overview over the backlog and understand what the user really wants and what’s important.

If you’re already using Scrum or User Stories in general, and you’re wondering why proper naming for your User Stories is important, think about the last time you looked at the backlog and how easy it was to identify what should be the next thing you should be doing (maybe during Sprint Planning) without going into every single User Story in detail. Think about trying to identify all the dependencies for a specific feature / requirement, without going through all the backlog in detail. If it takes time for anyone in the team to get the right clarity and understanding regarding what needs to be done, why and in which order, chances are that something is off with the backlog and most likely with the naming of the user stories.

What would go into a User Story?

As already portrayed in the previous section, the User Story’s name is extremely important to establish and inform upon the WHY, to ensure the purpose is always at eye level and to ensure the focus is on what’s important. However, as we get closer to the implementation we need to ensure the entire team will have enough clarity into the details of implementation, including architecture decisions, standards to be used, etc. And that would definitely not be part of the name of the User Story, but rather in its body (content, description or however you want to call the details).

Different teams have different expectations regarding what a User Story needs to include, to ensure efficient delivery. Unfortunately there is no secret recipe that would guarantee all-time success. Adding too much content and details can add significant time pressure over the Product Owner, who’s usually in charge in defining these User Stories. Too little details will generate delays in the development process as the team will always come back to the Product Owner to ask for clarifications or, by not asking the relevant questions, they would go on the wrong path and eventually generate a lot of so called waste (basically work that would need to be re-done or defects that could have otherwise been prevented).

Finding the right balance between the level of details and the time taken to provide them is critical for any team. Usually it takes a few iterations (sprints) before this balance is achieved. Good Agile teams will constantly work with the Product Owner and the Scrum Master to identify ways to optimise the level of details of these requirements, so that the Product Owner spends less time writing and more time focused on delivering Business Value.

Putting too much details into User Stories that will not be implemented in the next 4-6 iterations is usually a waste of everyone’s time because by the time the Story is actually picked up in the current sprint, the expectations will vary and even the requirements might change significantly. As we work on the product, we learn more about what we know and even more about what we don’t know, and this usually has a ripple effect over the entire work that hasn’t been touched already.

Assuming you are looking at a User Story that would go into an upcoming sprint, you should be able to see at least the following details:

• Description : this should be a more detailed explanation of the actual name of the User Story, focusing on maintaining the same level of clarity regarding the purpose (just in more details)
• Acceptance Criteria: probably the most important aspect of the HOW, acceptance criteria are critical in conveying the business requirements to the team. Because even if as development teams we can come up with tons of ideas, when we get down to implementation we should ensure proper alignment with the business goals and expectations.
  Acceptance criteria must cover feature boundaries (what is included in the story and what isn’t), happy flows and corner cases alike, as well as test scenarios to be covered.
  There are different ways in which acceptance criteria can be expressed, but the most frequently used are checklists (simply listing out a number of capabilities and lower level requirements that should be implemented), or, in more Agile oriented teams, the BDD (Behaviour Driven Development) approach is often encountered.
• Visual artefacts can significantly increase clarity and provide visibility into expectations. These are usually User Experience / User Interface related, but they can also cover Architecture, Infrastructure, Database Diagrams or code-level design specific clarifications designed on the proverbial napkin in a pub (captured as a picture) can be used and attached to the user story if it serves the purpose of increasing the clarity and reducing the friction.
• Technical decisions and expectations are also critical in complex / complicated features, especially when an in depth analysis and technical evaluation preceded the actual implementation story. These decisions are usually contributed by the Technical Leads, Architects or other specialised team members or external contributors (such as Database Administrators, DevOps engineers or others).
• Non Functional Requirements are often overlooked when defining the user stories, but they are critical in ensuring that the quality attributes of the application are being delivered. Security, performance and availability, to name just a few of the common NFRs, should be defined for each individual User Story (of course, as much as it makes sense).
• Dependencies & Links to relevant User Stories (both previously implemented or strictly planned for the future) can add increased clarity into the scope and boundaries of the current User Story. Not to mention that linking User Stories properly with tagged relationships (e.g. Depends On, Relies On, Blocked By, Blocks, etc.) is improving the way the Backlog Management Tools (such as Atlassian Jira) can significantly optimise the development workflow and the prioritisation process by identifying the critical path for certain features & functionalities with ease.
• Attachments: whatever additional content that can be attached to ensure everything is in one place… well… should be attached.
• References: they say a picture tells a thousand words… I would say experiences can say much more. If the team already has the mental picture of how a certain feature previously done was implemented, it’s easier to mention that in the new Story rather than explaining everything again. So if there are such anchors that you can use (as long the approach will be identical), use them in your favor.

Keep in mind that many development teams are developing requirements fatigue at some point, meaning that the more content you will add to the User Stories, the easier it will be for them to miss and/or ignore important details. Therefore, keep the information to the minimum, adjust the amount of details you add constantly (maybe every other Sprint Retrospective spend a few minutes looking at how the User Stories can be both improved and simplified).

How much (functionality) should usually go into a User Story?

This is a tricky question… and the answer is the standard “consultant” answer: it depends. User Stories should be as large or small as they should be. I’m sure that this explanation doesn’t help at all, so let me try to expand on it.

The User Story is as large as the delivery effort associated with it, not as the effort required to define it or as the amount of content and documentation it holds. As we should be releasing features to our users (for testing, acceptance, validation) at the end of each iteration, having User Stories that take more time than the available time of a sprint is not an option. Given that sprints would usually last 2 weeks (according to what most of the teams adhere to), having stories that take more than 9 days to completely develop and test should be avoided.

But even if we’re able to fit a User Story in a sprint, the risks associated with stories that are filling all the time available are quite high. Any unpredictability translates into delays and stories will end up being dragged from one sprint to another.

Ideally any user story can be implemented, fully tested and delivered according to the Definition Of Done criteria within 3-4 days tops, as even in a worse case scenario a Story having that original estimation would still fit the current Sprint.

As User Stories are usually built around outcomes and purposes, it is clear that sometimes the implementation required to generate those outcomes can be quite beefy. Working on such stories can take more time, leading to delayed testing & validation and eventually introducing a significant amount of risk in the entire product.

Therefore, the solution would be to split them into smaller User Stories. We might think that this would be the norm in most situations, but there are also many situations that would rather point in the direction of having larger, more complete user stories.

To really understand the difference between using smaller, simpler User Stories and bulky, more rounded and complete User Stories, let’s look at how we can break User Stories into smaller ones and what are the pros and cons of this operation.

How can we efficiently break User Stories?

A large user story is usually an Epic in camouflage. Such a story should be fairly easy to break down. If the User Stories handle too many things at once (ex. Login, registration and password recovery), it is clear that different functionalities should belong to their own individual User Story. However, sometimes these details are not so obvious. What options do we have?

1.) Splitting User Stories based on User Type, User Role or User Persona

When the functionality described in a User Story has particularities specific to different User Roles, Types or Personas, the Story can be broken down into different stories covering each different roles as well as one or more stories covering the shared & overlapping functionality.

The user types can be identified based on the actions they can perform in the application, the different levels of access they might have, or the different ways in which they can access some of the information.

For example, in an online store we can identify the following user types:

• The visitor (unauthenticated, with no previously created account)
• The registered visitor (has previously created the account but is not logged in yet)
• The user (has an account, is authenticated, but the user hasn’t been confirmed / verified yet using SMS, email or other KYC methods)
• The verified user (just like regular user but with the KYC completed)
• The store administrator (manages anything on the back-office of the application)
• The support operator (is able to search for orders, products, customers, etc. and can operate the support tickets).

Many more individual roles and user types can be identified, and for each one we will identify a partially or completely different behaviour and experience within our application. This can lead to specific user stories which will handle those differences.

A special case would be the so-called ” Virtual Personas“, or personas that don’t actually exist but we should still think about them. These personas would mainly be defined around non functional requirements. For instance, the _ Hacker _ can be considered an “Anti-Persona” and capabilities designed to protect the application against this nasty user type can be moved to a separate user story.

Similarly, we can consider various 3rd parties, interested in our application, as a potential persona, and deal with the details specific to their “requirements” into separate stories. For example, Google can become a Persona, or more generically, the Search Engine. While this might sound weird, once you learn that some features might require specific adjustments to be indexed by Search Engines (e.g. to be SEO friendly), it starts making sense to consider addressing the SEO requirements at a later stage, in other words satisfy this particular Persona’s interests in a different story.

2.) Splitting User Stories based on specific record level operations

Many apps provide different ways their users interact with the data / records. Users can create records, can modify or delete them and of course can browse, view, query the previously defined records.

Trying to provide the full data management experience and capabilities makes a lot of sense when dealing with simple data and with simple inputs and limited validation requirements. However, when the records have a complex structure or validation rules, when some changes are done and recorded in a more transactional manner rather than simple edits (for instance approving an order does more than simply updating it’s status in the database) – in other words when the complexity increases – it is usually recommended to separate some or all of the potential data management operations:

• Creating records
• Updating records
• Deleting records
• Browsing records
• Viewing a single record

Different transitions or transactions should also be handled independently as part of individual User Stories, to ensure functionality is delivered and validated gradually. This also ensures that after each partial implementation any detail that was not clarified ahead of the implementation becomes now a clear definition in the remaining stories.

3.) Splitting User Stories based on collateral capabilities

Many Product Owners consider that a User Story is completed only when all the features, capabilities, bells and whistles are done and ready. But this prevents proper validation of the feature since it takes more time to build all of the less relevant capabilities on top of the core functionality.

Take for example a simple product browsing feature. Browsing the products might mean also search, filtering and pagination for some, while those interested in a faster validation of the user experience and the interactions specific to the list of products might consider leaving aside those extras for later.

When we look broadly at data listing capabilities, we can separate the core (actual listing) from the extras (searching, filtering, pagination, sorting, grouping, expanding & collapsing details, bookmarking, comparing records, cloning records, etc).

If you’re using a platform that provides those capabilities out of the box for any type of records (e.g. using a CMS, a code generator, etc.) it’s obvious that we will not separate the core from the extras, as they usually come in as a package. However, when we implement those features from scratch, at least in the initial implementations the features will be separated. Hopefully, using a good design & implementation structure, we will be able to leverage those initial implementations later down the road and allow full-fledged stories to be worked on at once rather than working with granularly defined stories.

Sometimes deferring some features would not even impact the users in a negative way, as for a while (during the initial adoption) the lack of those extra capabilities can be compensated with smart default behaviours. For instance:

• Rather than adding advanced search functionality, make sure you only display in the first iterations the data that will be relevant to the users
• Rather than implementing advanced paginations and continuous scrolling, simply display the records from the most X recent days, ensuring that the user will not necessarily feel the need to go through pages of records to get what they need.

This approach ensures that while we defer additional functionality for later, our application is still usable and we can collect valuable feedback from our users.

4.) Splitting User Stories based on API/Back-end vs UI/Front-end requirements

If we look at our back-end strictly as a support layer for the user interface, it’s obvious that we will see no value in delivering API / back-end only features. However, when we start looking at the API as a standalone product (especially when we can monetize it), then delivering API level features becomes a more interesting approach, because the API would deliver value to multiple integrations, both with User Interface applications or with other apps & services.

In this context, those API capabilities can be managed as independent user stories, considering all their use cases and integrations, while the UI stories will focus on particular use and integrations within the application at hand.

However, when using this approach, we always need to make sure that the API is being developed and delivered in collaboration with the actual users of the API and that their use cases are covered by the API tests that are created along with the API (which should be part of the Definition Of Done).

5.) Splitting User Stories based on the User Interface platform / operating system

The majority of modern applications currently provide support for multiple User Interfaces with small variations derived mainly from the differences in those actual platforms but also from the expectations and behaviours of the users on those particular platforms.

For example, we can discuss different browsers as support for the UI of web applications (e.g. Chrome, Safari, Firefox, Microsoft Edge, etc), different variants of the website (mobile version vs desktop version), different operating systems for desktop apps (Windows, MacOS, Linux), different Linux distributions (Ubuntu, CentOS, Fedora, etc.) or different mobile operating systems (Android, iOS).

When each of these different platforms require a native implementation (such as implementing a feature for mobile both for Android and iOS platforms), web applications and hybrid applications (Ionic, NativeScript, Xamarin, React Native, etc) allow us to build for all our target platforms at once.

However, due to minor (but utterly annoying) small differences between these platforms, we can sacrifice significantly more time on addressing those differences than we should. A defect in a 3rd party platform specific library or a difference in the supported HTML5 APIs of a specific browser can derail our plans regarding releasing a specific feature.

The solution here is to pick a main platform based on the highest compatibility, release the features for that platform first, and address the differences in incremental releases and therefore in additional user stories. Additionally, features that require a platform specific approach altogether should be by default defined in separate User Stories.

6.) Splitting User Stories based on Happy Flows vs Exception Paths

Dealing with all exceptions and corner cases in a feature, especially in a complex one, makes absolutely no sense when we want to get to the point of user validation. In these situations we can create a main story focused on the so-called Happy Flow, or ideal flow, with some minimal validations and exceptions incorporated, enough to ensure that just in case the proverbial fan is being hit we’re not going to have a lot of cleaning up to do. In other words, the major risks should still be addressed along with the initial implementation, even if we defer the most complex exception paths for later.

7.) Splitting User Stories based on the Visual hierarchy

Especially when working with complex applications and User Interfaces, we can come across situations where the UI consists of different layers of components and we have a visual hierarchy of User Interface elements (called controls or components).

While we might believe that having the different layers (e.g. parent control vs child controls) delivered separately, there is a lot of value in “releasing” them separately, at least internally, and to be able to validate them before we spend effort on building complex integrations.

The common approach in this situation is to identify the different individual and independent components in the complex hierarchy, prioritise them based on the level of reusability and upon development publish these components in a sandbox (where all stakeholders get to play with the components in a simulated environment). These days, a popular sandboxing solution for showcasing the components is https://storybook.js.org/. This approach allows developers, designers and testers to work on different independent components from different levels of the visual hierarchy of the application, delivering value (even if for start that value is visible only internally) and moving faster and better towards a releasable user interface.

8.) Splitting User Stories based on Learning generator vs Value generator

We’re often working on features where most of the functionality is clear, but to be honest, quite often it is less clear than it should. Many details still have to be gathered from stakeholders, many requirements are shady at best, therefore it would be impossible for any team to commit to deliver a feature that is so “abstract” to say the least. Deferring the entire functionality until we find out everything we have to might turn opportunities into missed opportunities.

As we all hate when that happens, there is a solution. We split the capability we want to build into 2 User Stories (or more):

• The learning generator, consisting of parts of the functionality that are not clear, leading to some more insights and better understanding of the problem
• The value generator, consisting of parts of the functionality that we could monetise or at least validate early.
• Any additional glue kind of stories that would ensure the necessary dependencies are being covered

What are the pros of breaking User Stories into smaller ones?

• Having smaller User Stories, focused on part of the functionality rather than the whole, would allow us to get the validation and feedback from our users and stakeholders faster.
  Especially when we don’t know all the details and we don’t know everything about particular scenarios, it’s always better to put our apps into the hands of people that can hint us if we’re going in the right direction or not. A feature not published is a missed opportunity to receive feedback, so why not take advantage of this earlier rather than waiting until all the specifics are implemented?
• When splitting a User Story into multiple smaller Stories, we can focus on those items that are generating the maximum Business Value with minimal effort , even if in the long run we might have to cover the less important features as well in order to ensure a proper user experience.
• When we’re working on more complex functionalities, it is a common situation to miss details or even larger parts of the requirements. Because sometimes we don’t know what we don’t know, we can only overcome the lack of know-how by learning on the go. In many situations the “big” User Stories can only be defined once one or more smaller stories have been completed, with the sole intent of generating learning / knowledge, to clarify possibilities and boundaries. These are usually Proof Of Concepts and are sometimes called Spikes. These can be time-boxed (with limited time allocated), enough to discover what needs to be known before we start working on the important story.
• Ever spent significant time on an idea that sounded really well, a feature that seemed to be the next big thing, only to throw it (or most of it) away as soon as it hit the users? It happens to the best of us, no matter how much prep work we’re doing. As we can validate smaller features faster, we can also prevent large portions of the stories to become waste, to be thrown away , by developing smaller features following actual user demand.
  If we consider the amount of rework & change caused by user feedback, we can already see that reducing the size of the product and feature increments we get the feedback for can also lead to less waste in case those features have to be changed (or when the remaining bits of the features are no longer needed or relevant for our users). This goes back to accepting the idea that we might not completely understand our users and their expectations and we will most likely have to pivot some of the features.
• Any misunderstanding on the development team side will be detected and addressed much earlier when working on smaller User Stories compared to the longer and more complex ones. This also helps any necessary process adjustments to be fed back into the remaining items from the backlog, ensuring more clarity and a better delivery going forward.

What are the cons and risks of breaking User Stories into smaller ones, and how can we prevent them?

• When breaking down User Stories in order to achieve faster user validation, it is commonly encountered a separation of the functional requirements from the non-functional requirements , which are being moved to a separate User Story. The risk here is that the feature might be considered completed as soon as the User Story containing the functional requirements is completed, missing out on the NFRs (such as security or performance) and opening up a number of risks.
  This might be acceptable for validation with a set of trusted users, in a controlled environment, but it might not be a great idea to do this with production releases. To prevent this, there should be a quick procedure to ensure the dependent user stories containing NFRs are being reviewed before a feature is released in production, to minimise the negative impact.
• The same risks can manifest when the breakdown was done around happy flows vs remaining functionality. Prevention, similarly to the previous scenario, would be done with a simple but strict and thorough review before releasing a feature in production.
• A User Story can depend on another story (part of the same initial parent story) that is not yet completed. Due to this, neither of the two stories can be released. Prevention and mitigation rely on a better planning:
  • Each story has clear deliverables identified and we ensure that not many stories depending on an uncompleted one would be started within the same sprint.
  • We document the interfaces and dependencies (APIs, Databases, shared components, integrations, etc) and use mock implementations whenever possible and useful.
  • When multiple stories have overlapping areas, these should be identified and developed early in the sprint , and the effort will branch out on individual stories only after the overlapping areas are covered.
• Focusing on the smaller User Story, immediately in our scope, we might lose sight of the bigger picture and get into the uncomfortable zone of doing frequent rewrites for certain features in order to accommodate new requirements and things we missed. To prevent this, we need to ensure that:
  • For each User Story we have clearly articulated and defined the broader scope , and all dependencies and related stories are being linked.
  • We apply good development practices and principles, such as the well known SOLID principles (at the very least Open Close and Single Responsibility Principle). Using this we ensure the solution is flexible enough to accommodate new requirements without too much rework, while keeping the solution relatively simple and with no over-engineering.
  • We always refer our stories to a higher level requirement entity (the Epic) where we provide an overview of the bigger picture.

 

Closing Notes & Conclusions

User Stories are a powerful tool for teams and Product Owners alike to deliver great products in an efficient yet innovative manner. While there is an initial complexity associated with the in-depth understanding of the way User Stories should be written, we can always start small and improve with every story we write by learning, inspecting, reacting and adapting, just the way we’re supposed to in an agile environment.

While this article covers some of the ways the User Stories can be broken down into smaller ones and different types of details that the stories could contain, your team and product are unique in the sense that they might require something slightly different for them to achieve high efficiency and agility.

Experiment and adjust continuously and eventually you will reach that point. And then again, from time to time, experiment just a little bit more to ensure you’re not stuck in a way of doing things that is no longer tuned to your team & product state. As the team matures or some of the team members change, adjust the way you work to reflect the new reality.