One of the main steps in every Scrum project is the commitment of the team to delivering the user stories by the end of the Sprint, and we know how binding this undertaking is for every client. That commitment inevitably creates an expectation that will become disappointment should the team fail to deliver.

Amongst the different reasons that could prevent the team from honouring the commitment, the (incorrect) size of the user stories is probably one of the most frequent. The frequency might be even higher if you are working with teams whose composition is not constant across projects.

The problem with big stories is that they suffer from greater uncertainty and slow down the flow (as they move slower towards the “done-done” status). Smaller stories, instead, are easier to estimate and allow for a broader understanding of what is needed.

The most common reaction when dealing with big stories is the team trying to make story smaller without agreeing on a particular approach. People that are less used to work in an Agile environment will likely try and split user stories horizontally. That is the worst possible approach since it usually drives the team towards a split by discipline, and the “iterative waterfall” approach casts its shadow over the project.

That is the moment for the project manager to take her “Scrum Master” helmet off, put the “Coach” hat on, and help the team finding the right method and ultimately the right size.

Is a story too big?

During a backlog refinement session, every team member should question himself whether each story is the right size or not. If you are estimating using effort the issue should be “When you think about working on this story, do you feel it is about days or weeks?”.

If the answer is “weeks”, then we can most certainly flag that Story for a new conversation to split it.

If you are estimating with Story Points, it probably depends on your average velocity. Stories should comfortably fit in a Sprint. Therefore, any Story sized more than half a Sprint should probably raise some concerns. Based on your lessons learned you might also decide to put a hard limit and review any story greater than or equal to 8 points, for example. Just bear in mind that, since story points are not an absolute measure, that limit could be anywhere, and you could work in teams that comfortably handle 13-point User Stories.

Ground Rules

Before thinking about how to split a Story, you should remind the team that they are not delivering User Stories but Business Value. Therefore, any division that generates a story with no Business Value is wrong by default, regardless of which method you used.

That is, of course, another reason to avoid horizontal splitting: if we delivered only a story about the design of a feature, for example, it would not add any value to the product.

Method 1: Split by workflow

If a story is describing a user journey of some kind, maybe we could decompose it into stories each representing one of the main steps. The whole operation would allow the team to get a good amount of details on the user journey. Example:

As a user, I want to log into the website so that I can submit comments to the articles.

This story will likely have many acceptance criteria about the authentication, password recovery, and notifications, but we could easily decompose it into:

  1. As a user, I want to log into the website so that I do not have to re-enter my personal information every time
  2. As a user, I want to add a comment to an article so that I can provide the author with feedback
  3. As a website moderator, I want to review comments submitted by authenticated users so that I can block inappropriate content
  4. As a user, I want to receive a notification when my comment is approved
  5. As a user, I want to get a notification when somebody replies to my comment so that I can read the reply

Method 2: Split by business rules

Sometimes there are clear business rules behind a story, and we could use them to break it into smaller chunks of work. That maybe one of the most elaborate methods since business rules are not usually explicit.

Considering the same example as the previous method, we could decompose the story into:

  1. As a website manager, I want to automatically reject comments containing particular words so that I can increase the quality of the content.
  2. As a website administrator, I want to delete automatically comments that haven’t been approved in 15 days, so that I keep the queue smaller.
  3. As a website administrator, I want comments to be automatically approved if the writer already had two comments previously approved so that I can keep the queue smaller.

Method 3: Separate the happy path from the sad one

Similar to the split by workflow, this method involves the separation of the happy path (the positive user journey) from the sad one (the journey when something goes wrong).

Let’s stick to our example. The split would likely be:

  1. As a user, I want to log into the website so that I can access private features(happy)
  2. As a user, I want to retrieve my password when my login fails so that I can try again to log in (sad)
  3. As a website administrator, I want to lock out a user that failed three times the log-in, so that I can protect the site from attacks (sad)

Method 4: CRUD

CRUD is an acronym that stands for “Create, Read, Update, Delete”. Having this four operations in mind, we can decompose stories that involve items management. We can still use our previous example and decompose the story into:

  • As a user, I want to create new comments so that I can add my feedback
  • As a user, I want to read comments so that I can be informed about the opinion of other readers
  • As a user, I want to update my previously inserted comment so that I can amend mistakes and fix typos
  • As a user, I want to delete my comments so that I can remove a feedback I am not sure about

Method 5: Split by roles

If the product you are working on has different access levels according to the group the users belong to, you could slice stories by user roles. In our example:

  • As a visitor, I want to read comments so that I can be informed about the opinion of other readers
  • As a registered user, I want to submit a comment so that I can provide my feedback
  • As a website moderator, I want to review comments before publishing them so that I can ensure they complies with the code of conduct
  • As a website administrator, I want to delete comment so that I can control the quality of the content

Method 6: Split by datatypes

Some stories that involve managing data could allow for datatype slicing, i.e. by the way data are handled. The clearest example is surely a feature involving database queries such as:

As a user I want to perform a search on the website so that I can find content related to the keyword I inserted.

After discussing the story with the Product Owner, we could split the story into:

  • As a user, I want to search for a keyword in the title of the articles so that I can find content I am interested in
  • As a user, I want to search for a keyword within the content of the articles so that I can find content related to my interests
  • As a user, I want to find a keyword amongst the labels of the items so that I can find content more strictly related to my interests

In conclusion

I mentioned just a few methods, but there are many other ways to split stories, for example by acceptance criteria or by test cases.

Ultimately, breaking down stories is a fundamental activity of every backlog refinement session. It helps to ensure that the team has a good understanding of the requirements and gives the product owner the chance to identify an MVP easily. In that regards, as the project manager, you will find yourself dealing with difficult Product Owners that are less willing to give up some requirements even if the project has fix budget. In that case, whatever the method you are using, try splitting by “must have” vs. “nice to have”. It will be easier for the PO to renounce to the second and decrease the scope.

 

Share This