Split a User Story in Two
One of the user stories in our quiz feature was:
As a teacher, I want to choose between questions that have a single correct answer and multiple-correct answers so that I can test my students' knowledge when there is more than one correct answer.
The problem with this user story is that it contains two things (single correct answer quizzes & multiple correct answer quizzes). You can break this user story down into two user stories like this:
As a teacher, I want to add questions with one correct answer so that I can test my students' knowledge when there is one correct answer.
As a teacher, I want to add questions with multiple-correct answers so that I can test my students' knowledge when there is more than one correct answer.
Explore the Atomicity of User Stories
Dictionary.com defines atomicity as:
the state or fact of being composed of indivisible units.
Can you make a user story atomic? Yes! It means that you cannot break the user story into a smaller amount of functionality.
There are several benefits to having atomic user stories:
The product manager can prioritize so that the team can work on one of the stories above (e.g., single choice answers) and not work on the other initially.
Estimating user stories improves when they are at their smallest.
If the team works in short 2-3 week cycles (sometimes called sprints), they can build, test, complete, and release user stories during that period if they are small.
Add or Remove User Stories
Product requirements change over time. Therefore, as you discover and better understand your customer's needs, you will have to update the acceptance tests.
You may already wonder if removing independent user stories from a table is possible without affecting the remaining user stories. Yes! And it's the benefit of writing atomic user stories.
Adding a user story should be the same, although you should check that the current user stories do not overlap with the one you are adding.
For acceptance tests, it is the same. Suppose you realize that one example (or scenario) is no longer something you need to support. In that case, it should be relatively straightforward to remove an acceptance test from your list without affecting the others.
Use Tables in Confluence
If you store user stories and acceptance tests in a Confluence wiki, then:
Adding a story/test requires adding a new row to your table of stories/tests.
Removing a story/test requires removing that row from your table of stories/tests.
You will see these options in the Edit Page menu:
Let’s Recap!
In this chapter, we discussed how you can split, add, or remove user stories and how you can add or remove acceptance tests from a wiki. Remember:
There are many possible ways to split a user story. One popular method is to split by positive and negative use cases.
The split user stories should show a successful outcome (positive) versus ones that will either fail or lead to an error (negative).
We should make user stories as “atomic” as possible to help us find ways to split user stories.
Some common ways to split user stories are by customer persona type, product component type, customer criteria.
All user stories, regardless of size, should be valuable. We should favor the type of split that meets all (or as many as possible) of the INVEST criteria.
Now that we can add and remove our user stories whenever we need to, let's check out the next chapter, where we will create a Wiki with Notion.
