You may hear your Project Manager or Development Team assigning “relative points” to user stories. They are describing (“estimating”) the level of effort that a story will require to be completed. Stories with low numbers or small levels of effort will be completed more quickly than stories with high numbers or large levels of effort. Stay consistent with whatever system your team is using to estimate the stories, as this will help you manage the product backlog better.

If you end up with more than a few stories that will take large levels of effort, you should split those stories into smaller ones. This will be helpful in two ways:

  1. Splitting stories into smaller parts can help you identify and abandon any stories with “low-value functionality” — they require too much effort for their low yield benefit.
  2. When you have stories that are equally sized with smaller point values, it will be easier for you as the Product Owner to prioritize the parts of a functionality separately. This comes in handy later when you start to manage the product backlog.

Here are some tips from Agile coach and guru Richard Lawrence on splitting large stories into smaller ones:

  • If there are workflow steps to your story, break down the middle steps into their own stories. Example: “I want a CMS that will allow me to post a new article on the agency’s main website.” There are several middle steps required to achieve this goal, such as “Post article to a staging site,” “Get approval from editorial,” “Migrate article from staging to production.” Make each of these into their own story.
  • Different business rules should be different user stories. Since business rules often end up defining the functional specs for a feature, they should be parsed out as their own story.
  • If you have a story that states that it wants to achieve A with methods “X, Y, and Z” you have a story with an inherent dependency. Oftentimes the story assumes that the first method in the sequence (X) will involve the most effort so Y and Z can be tacked on with minimal effort. But what happens if your boss tells you to change it up and make sure Z works before X does? This will change your estimation on the levels of major effort! In such a scenario, it’s better to write the story in one of two ways:
    1. It can achieve A with only one method.
    2. After confirming that it can do A with one method, it can do A with all of them.
  • Break down a complex story into simpler ones. Example: “I want to search for meetings between office A and office B”. The what-ifs of this story will add up quickly for different use cases. Turn those use cases into their own user stories with their own distinct acceptance criteria (e.g. search for meetings with a certain number of attendees, by location, dates, etc.)
  • Be willing to change as new data and information are obtained. First come to an agreement as to what exactly “good enough” is for the simplest thing you can build right now — you can add high-value features later on. As you become more informed, split new stories as the new data rolls in.
  • A complex user interface can really complicate a user story. Start off with a story for the simplest UI and split new stories for fancier, more useful UI.
  • Time matters. Split a story between a “make it work” use case and “make it fast” use case.

Sometimes the implementation of a story is not well understood. Break the story into two phases: an investigation and the implementation. The acceptance criteria for the investigation phase should be questions you need answered. Only do enough investigation to answer the questions — then learn from it, build something, and proceed from there.