Splitting a User Story
One of the user stories we had in our Quiz feature was the following:
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). We can break this user story down into two user stories like this:
As a teacher I want to enter questions that have a single correct answer so that I can test my students' knowledge when there is exactly one correct answer.
As a teacher I want to enter questions that have a multiple-correct answers so that I can test my students' knowledge when there is more than one correct answer.
Atomicity of User Stories
Dictionary.com defines atomicity as:
the state or fact of being composed of indivisible units.
There are several benefits to having atomic user stories:
The product manager can set a priority so that the team can work on one of the stories above (e.g. single choice answers) and not work on the other initially.
Estimation of user stories improves when stories are at their smallest.
If the team works in short cycles (sometimes called 'sprints') of 2-3 weeks, it is more likely that user stories will be built, tested, completed and released in that timeframe if they are small.
Adding or Removing User Stories
Product requirements change over time. As knowledge is learned and as our customers' need is better understood and discovered, the user stories and acceptance tests will need to be updated.
You may already be thinking to yourself that if user stories are written so as to be independent, then removing a user story from a table of user stories should be possible without affecting the remaining user stories. This is indeed the intended benefit of our approach of writing atomic user stories.
Adding a user story should be the same, although we should check that the current user stories do not overlap with the one we are adding.
For acceptance tests, it is the same. If we realize that one example (or scenario) is no longer something we need to support, then it should be relatively straightforward to remove an acceptance test from our list of acceptance tests without affecting the others.
Using 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 our table of stories/tests
removing a story/test requires removing that row from our table of stories/tests
You will see these options in the Edit Page menu but I will also highlight them below:
In this lesson, we discussed how you can split, add or remove user stories and how you can add or remove acceptance tests from a wiki.