Story Splitting Kata

Last Friday we had a beautiful kata on splitting user stories. This skill is extremely important for agile teams as they have to be able to reliably:

a) Split user stories into smaller stories that fit into a sprint. And more so, good if they take few days, not a whole duration of a sprint, to keep the sprint outcome more predictable, and...

b) Split these smaller stories in even smaller cuts (which still are user stories), not necessarily explicitly, so that one cut will be the result of a single "Define-Build-Test" cycle.

We had six people + me, this is max to have kata exercise going really efficient. Especially this group was really and quite concentrated on the effort entire 90 minutes period. In the beginning the group comes up with the idea of a product that everyone can understand (in our case that was online currency converter supporting multiple different sources of exchange rates). Then we write first big epic and split it to as many user stories as we can. Eventually quantity translates into quality as we use different methods to split stories and acquire deeper and deeper understanding of the functionality and bounded context.

Alex Ginda was assisting me along the process, agile master and the photographer :) I appreciate his effort and grateful to Luxoft training center for providing us with the facilities.


  1. Hi, Alex!

    Very interesting post! Don't you think, though, that the effort invested in splitting stories could be better used in developing the features needed by the product? I mean, what if we could work with the features, with a development cycle around a feature, instead of splitting features into smaller stories just to fit our artificial iterations? This is possible using a Kanban approach. What do you think about Kanban?


  2. Well, this is very good question, Tiago, as it identifies another aspect in Scrum vs Kanban comparison. Though Kanban can simply become a sub-optimization if instead of splitting user value, we spend our time only on the implementation. "Big packages" are truly anti-lean (makes no sense to go into detail here but rather to direct our readers to "The Principles of Product Development Flow" by Don Reinertsen). Instead what is important is reducing value creation cycle to reduce the variability of the outcome. Iterations are not crucial here, but keeping the "packages" small really is.

    Overall, Kanban can be powerful method in many cases, but it may also create false feeling of staying busy with tasks, even though the team will be struggling against simplest laws of queue management (like in case we were discussing).

    Eventually, I hear the term "artificial iterations" quite often, but if we think about it for a second, we can same way call, for instance, acceptance testing an artificial usage scenarios, why not?

    Kanban certainly has good ideas behind it but it should not turn into nihilism but instead wisely exploit great heritage of agile requirements management techniques, XP engineering practices etc.