Story reflect the complexity of the problem, and so, reflect the confidence of how accurate the estimate is. A Story with a high story point tells you that there's a lot going on with the user story that isn't concrete.
If you are being shown an iteration plan with stories with all high story points, this gives you little confidence that the iteration will be executed as expected and that you need to look at other stories for the iteration or start breaking stories down.
When communicating with a Product Owner, high story points mean that it will be extremely cloudy as to when they will get a particular feature. One of the solutions to this is to break the story down and hopefully you'll have a combination of low and high story points to work with so that you can iteratively demonstrate progress to the Product Owner.
Important considerations for writing user stories:
>>Stakeholders should write user stories:
It’s an important concept that your project stakeholders should write the user stories, not the developers. Stories are simple enough that people can learn to write them in a few minutes, so it makes sense that the domain experts write them.
>> Remember non-functional requirements:
Stories can be used to describe a wide variety of requirements types.
>> Indicate the estimated size:
One way to estimate is to assign user story points to each card, a relative indication of how long it will take a pair of programmers to implement the story. The team then knows that if it currently takes them on average 2x hours per point; therefore the user story will take around 10x hours to implement.
>> Indicate the priority:
Requirements, including defects identified as part of your independent parallel testing activities or by your operations and supports efforts, are prioritized by your project stakeholders and added to the stack in the appropriate place.
Prioritization approaches are possible priorities of High/Medium/Low are often used instead of numbers and some people will even assign each card it's own unique priority order number You want to indicate the priority somehow in case you drop the deck of cards, or if you're using more sophisticated electronic tooling. Pick a strategy that works well for your team. You also see that the priority changed at some point in the past, this is a normal thing, motivating the team to move the card to another point in the stack. The implication is that your prioritization strategy needs to support this sort of activity. But keep it simple.
>> Optionally include a unique identifier:
The only reason to do this would be is if you need to maintain some sort of traceability between the user story and other artifacts, in particular acceptance tests.
Effective way to write stories:
>> Start with the initial users stories:
User stories are very slim and high-level requirements artifacts. And it describes how a user employs the product. You should therefore tell the stories from the user’s perspective. What’s more, user stories are particularly helpful to capture a specific piece of functionality.
>> Discover the right stories:
A great way to capture your insights about the users and customers is to use personas aka character. But there is more to it, The persona goals help you discover your stories.
Understand your target users and customers. After all, user stories want to tell a story about the users using the product. If you don’t know who the users are and what problem we want to solve then it’s impossible to write the right stories and you end up with a long wish list rather than a description of the relevant product functionality.
It offers a great way to capture the users and the customers with their needs. They are fictional characters that have a name and picture; relevant characteristics such as a role, activities, behaviors, and attitudes; and a goal, which is the problem that has to be addressed or the benefit that should be provided.
>> Write stories collaboratively:
A user story is not a specification, but an communication and collaboration tool. Stories should never be handed off to the development team. They should rather be part of a conversation: The product owner and the team should discuss the stories, or even better, write them together. This leverages the creativity and the knowledge of the team and usually results in better user stories.
>> Keep your stories simple and to the point:
Write your stories so that they are easy to understand. Keep them simple and short. Avoid confusing, unclear and ambiguous terms, and use active voice. Focus on what’s important, and leave out non-essential information. Use the template when it is helpful, but don’t feel obliged to apply it. Experiment with different ways to write your stories to understand what works best for you and your team.
>> Start with epics:
Epics are big, coarse-grained user stories. Starting with epics allows you to sketch the product functionality without committing to the details. This is particularly helpful for new products and new features: It allows you to capture the rough scope, and it buys you time to learn more about the users and how to best meet their needs. It also reduces the time and effort required to integrate new insights. If you have lots of detailed stories, then it’s often tricky and time- consuming to relate any feedback to the right stories.
Typically user stories which are too big to implement in a single iteration and therefore they need to be disaggregated into smaller user stories at some point. Epics are typically lower priority user stories because once the epic works its way towards the top of the work item stack, once you have created your personas, use their goals personas to identify the product functionality.
Epics are great to pictorise the product’s functionality; there is more to your product than epics and stories. You should also capture the user interaction and the sequences, in which the epics are used, the visual design of your product, and the important nonfunctional qualities such as interoperability and performance.
>> Break down your stories until they are ready:
Break your epics into smaller, detailed stories until they are ready: clear, feasible, and testable. Everyone should have a shared understanding of the story’s meaning; the story should not too big, and there has to be an effective way to determine if the story is done.
>> Add acceptance criteria:
As you decompose epics into smaller stories, remember to add acceptance criteria. Acceptance criteria complement the story’s narrative: They allow you to describe the conditions that have to be fulfilled so that the story is done. The criteria enrich the story and make it more precise and testable, and they ensure that the story can be demoed or released to the users and the other stakeholders.
>> Don’t completely rely on User Stories:
Creating a great user experience requires more than writing user stories. Also consider the user journeys and interactions, the visual design, and the non functional properties of your product. These results in a holistic description that makes it easier to identify risks and assumptions, and it increases the chances of creating a product with the right user experience.
