SECRET OF CSS

9 Tips to Improve Scrum User Stories | by Oliver Karst | Jul, 2022


Some tips to improve the quality of your Scrum user stories and make them easier to implement.

1*pDb
Foto lake Constance was taken by myself

Well-defined written user stories are a critical success factor. They improve the understanding and help to estimate the effort and finish the implementation.

Scrum says a user story should be a very short description. From my practical experience, some important information should be included to avoid questions and confusion.

While using a template the stories have a similar structure. The template should contain all parts that need to be covered by a story. This avoids forgetting important points and details. In case you don’t need parts for a specific story you can tailor them away.

(based on tip 1)

Many Scrum stories start with “As a user I want …”

Which kind of user? A reader user, an admin user, a new user, a maintainer user, etc. The permissions rights can be covered by a role. If you define user roles for your system they can be taken to user stories and you can choose which kind of user role the user has. “As an admin I want …”

Unfortunately, my experience is that many stories are written in advance before they can be implemented. Some stories need first that other stories to be finished before the story can be started. Some stories may have to wait for other conditions to be started. Teams using Jira tend to create backlogs with many stories that are not ready to start.

List the preconditions when a story is ready to be started to be implemented.

Many stories cover only the good path. When something is done then something happens. Sometimes it is worth covering exceptions. How to handle exceptions. The easiest thing is to log exceptions.

If you don’t cover bad path handling you will create technical debts.

This defines when the story is finished. From my practical experience, the use of acceptance criteria is useful when written in short sentences like easy-to-to-prove tests.

If the acceptance criteria are written well they can be used as input for automatic tests like unit tests or end-to-end tests.

If you describe a story it could be useful to write down the assumptions on which the story is based. This helps for better understanding and traceability.

You or technicians can add the affected technical parts of your story. Does your story only have an impact on the front end? Or does your story impact the database or backend as well? This information could be helpful as well to better understand the impact of the story while discussing story points in refinement.

Different reasons can make it useful to split a story into several. In Jira, it is possible to create an epic and assign several stories to that epic.

Stories should be small to be easier to estimate the story points and implement them.

Look in your team which stories are often not done at the end of a sprint. In some teams, stories with more than 8 story points are too huge for one sprint and should be split. If you decided to estimate effort my recommendation is that a story with 5 days of effort is already too huge.

Another indicator of a too big story is a list of acceptance criteria that is more than 2 or 3.

Some people add subtasks (in Jira) to stories. If there are more than 2 subtasks think about making subtasks to stories.

If the affected technical parts, see tip 7, show a list of more than 2 it could be useful to split the story and define them like “As a user with that role I want to add a field to the frontend” and another story like “As a user with that role I want that the value of this new field is stored and can be retrieved” for the database part.

In case of the needed interface to other systems, it could be necessary to get in contact with the people of the other system and confirm what you want to implement. Sometimes a schedule has to be synchronized.

If data from other systems is needed the interface specification needs to be clear.

A story should every time cover as well the technical parts. If you need to do technical stuff like an upgrade or update on system parts it should be a story like “As users of the system I need the security fix …”. Never start to create a special story type for technical things. The risk here is that some product owners tend to lower prioritize them or are uninterested in the outcome.

That list of tips is not complete. I am happy to hear about your experience and tips and feedback as well.



News Credit

%d bloggers like this: