Splitting a User Story along Acceptance Criteria

When breaking down a large user story to ensure it is sized appropriately, the default is to use Richard Lawrence’s excellent 9 Patterns for splitting a user story.

I also use an additional approach; in the first instance I look to see whether it can be split along its acceptance criteria. Every good user story should have acceptance criteria, and this approach ensures that not only do they exist, but they are also reviewed before we look to split.

My reasoning for doing this is as follows:

• A user story’s completion is binary; it is either ‘Done’ or ‘Not done’

• As a minimum for a user Story to be ‘Done’ its acceptance criteria must pass

• Good acceptance criteria must be testable, they should be worded so as to enable a yes or no answer (i.e. as per the user story the acceptance criteria is also binary)

Therefore a binary user story can be broken down along its binary acceptance criteria, to reduce complexity and create a set of smaller binary sub-stories.

As Richard Lawrence quite rightly points out - ‘complexity and effort are rarely distributed evenly across acceptance criteria; but acceptance criteria can be used as an indicator of what kind of complexity you have in a story, which would lead you to apply the appropriate pattern (which might cut through the existing acceptance criteria rather than between them)’

So let’s apply this approach to a user story example. How could we reduce complexity by splitting between acceptance criteria. I’ve taken this user story from Sandy Mamoli’s post on Acceptance Criteria

Example User Story:

As a Snapper cardholder

I want to be able to pick up my pending credit from MySnapper

so that I have money on my epurse

(Note: MySnapper is a client applications for users to top up their epurse, check their balance etc)

Example Acceptance Criteria:

1. I can see on MySnapper that there are pending credit(s) for my card

2. I can choose which credit(s) to pick up

3. I can see my new purse balance when I have chosen to pick up a credit

4. I can’t top up my card or buy a pass when there are pending credits for my card

The User Story has good Acceptance Criteria that show a clear intent and are binary; they could therefore be broken down as follows:

1.

As a Snapper cardholder

I want to be able to see if there are pending credit(s) for my card

so that I know whether I have funds to spend

2.

As a Snapper cardholder

I want to be able to select which new pending credits to pick

so that I have money on my epurse

3.

As a Snapper cardholder

I want to be able to view my updated epurse balance

so that I have an up to date view of credit available to spend

4.

As Snapper

I want to ensure a cardholder can’t undertake transactions when there are pending credits on their card

so that I customers do not go into debt

This approach certainly does not replace the 9 patterns for splitting a User Story, but I do find it a useful first cut to review the complexity of a story and at the very least start the process of splitting it down so it can be more manageable while still delivering value.