As I mentioned in one of my previous blogs in this series, when you are writing Acceptance Criteria for a User Story and the list keeps growing and growing (or there are multiple scenarios), then it might be a clue that it’s time to split that story into smaller ones.
The same thing applies if you’re writing endless Test Cases for a single story. I run into this all time – it’s more common than you might expect. I generally only discover that I need to split stories when I’m sitting in a Sprint planning meeting and the developers start asking questions – usually about things that never occurred to me.
One recent example comes to mind that I will apply to my fictional Recipe app. Let’s suppose that I’m the Product Owner for the app, and I want to be able to notify my users when there are new recipes to check out, important news about food, recent rave reviews, etc. I recognize that I will need to have a way to send these notifications out, and it sounds easy to me as a Product Owner. But when I start talking to the dev team, they suggest that we need to build an entirely different app for that!
What to do now? Time to start operating on the original big story:
My original story was something like this:
The Acceptance Criteria for this didn’t look too intimidating to me (from my Business Analyst’s perspective):
The Marketing Manager can:
- Send notifications to users
- Select which individuals or groups to send the news to
- Create/edit user groups and add/remove app users to one or more groups
- Include a picture with the notification
- Include a video with the notification
- Add a call-to-action with the notification
- Schedule when notification items will go out
Apparently, though, each of these Acceptance Criteria truly warranted its own user story as well as an entirely separate app that we ended up calling “News Manager”. I also ended up writing a host of stories from the customer’s perspective (remember the splitting approach by role?).
I won’t write all the stories out in this blog, but here is a small sample of what splitting the Acceptance Criteria into stories ended up looking like:
Etc.…
This turned out to be a much better approach. I also ended up writing stories from the app user’s perspective. What I thought was a relatively easy story to develop turned out to be much, much bigger than I originally anticipated. It was well worth the work to split the acceptance criteria into their own stories (and I’m quite proud of the results).
The same concept applies to Test Cases. If you have lots and lots of test cases or scenarios, that is yet another clue that the story is probably too big.
Questions to ask:
- Do you really need to have all the functionality described in the Acceptance Criteria delivered at the same time?
- Is there an opportunity to start with the most basic functions and then progressively elaborate on that base functionality?
- Can you look at each criterion and easily start rattling off additional Acceptance Criteria that apply to a single criterion?
- Is your development team questioning you (HINT: listen to them)?
- Do you have runaway test cases for a single story? It might be time to split….
Again, I run into this scenario more often than I’d like to admit. Thank goodness it’s a situation that’s easy to remedy by simply splitting the acceptance criteria or test cases into their own stories.
