One of the areas that many teams struggle with is getting user stories to the right level of context. For me context IS everything in user stories.
Yes a story is a placeholder for a conversation, but with large complex systems and organizations, the need to build out (and document) context has many benefits for teams and the organization.
Over the years I've seen some consistent elements fall out of BDD that can provide teams with an understanding of when a User Story may need to be broken down.
As you begin to build your test scenarios for your user story ensure that the story has no more than 3-4 scenarios. If the number of scenarios is large, getting a clear contextual understanding of the story becomes much harder. Additionally if automation is part of the equation then you end up with a larger code base for a single story and it can make trouble shooting failures harder. Smaller stories mean less complicated acceptance criteria and more manageable and scalable automation code.
Once you have identified your test scenarios and begin writing the supporting BDD acceptance criteria look for some of these elements as queues to potentially break down your stories:
- Large set of parameters- If you see that you have more than 7-8 parameters in an individual test scenario consider breaking the test into additional scenario(s) or another story. As I've taught my teams, if you see your example table stretching off the page you probably need to break it down.
- Large set of examples - If you see your test has more than 12-15 examples in an individual example table, you should consider breaking it down into additional scenario(s) or another story.
Keeping your stories and test examples small ensures that the team can more accurately estimate, deliver and demo their work consistently.
Teams should strive to break stories down so that they are small enough to be completed (Dev and Test) within 2-3 days. This level of granularity provides clear visibility during Standups if the team is on track to deliver on their commitment.
Many teams suffer from what I call 'pushing a river down a creek' syndrome. Meaning that they don't perform sufficient planning and story breakdown which leads them to continue to push their work out into future Sprints. This leads to a lack of visibility as to when 'it will be done/delivered'
Breaking down stories effectively also leads teams to have stable velocities which leads to predictable delivery. All of this feeds improved Program and Project management across the organization.
Organizations that need to scale Agile need to understand that this level of discipline isn't easy, but we shouldn't shy away from something just because it's hard.
BDD story breakdown leads to vastly improved feature definition, scalable automation suites and a strong automated regression.