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 by clicking on a row in the table:
Compare this to adding and removing a user story or some acceptance tests from a wiki. It is much easier to do and notify a team about it!
Let’s Recap!
Splitting user stories ensures that each story is focused and manageable.
Atomic user stories cannot be broken down further, making them easier to estimate and prioritize.
Small, independent user stories fit well into short sprints, enhancing productivity.
Adding or removing user stories and acceptance tests in a Wiki is simple and efficient compared to lengthy documents.
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.
