Think Small: Break Down User Stories for Agile Success
As an agile coach, my work revolves around helping teams learn and improve. When I meet a team for the first time, they are frequently either preparing to undergo an agile transformation or, having recently undergone one, are considering expanding or scaling agility in the enterprise.
In order to be successful in getting teams to be high-performing, we must take a stark and candid look at whether we are embracing the ideas of minimizing batch size. In agile terms, this means we must create and execute the smallest possible increments of value.
This is consistent with the INVEST mnemonic, which reminds us that our user stories need to be independent, negotiable, valuable, estimable, small, and testable. The small and estimable parts can be the most difficult to adhere to. Iterative elaboration of stories and good breakdown of features is difficult, thankless work. Estimating, as we can all agree, can produce a palpable sense of angst all in itself, and the pressure to maximize production and keep quality up can be overwhelming.
In the days of software development before agile, there were a few classic works that were considered required reading. One was a short essay by Hungarian mathematician George Polya called "How to Solve It: A New Aspect of Mathematical Method," which I highly recommend. This essay captures the essence of iteration and elaboration to solve complex problems. In addition, there is a helpful list of heuristics to employ, one of which is decomposition.
Decomposition is the principle by which we establish that the only way to solve a complex problem is to break it down into parts that can be more easily conceived, understood, improved, and executed. The same is true of user stories, which are intended to be solutions to customer needs. This paradigm can be applied to the entire value stream process and to the overall cultural improvement of an organization: Small improvements and changes are easier to support and complete.
So, how do we achieve smallness? The act of decomposition must be collaborative and iterative. The entire team needs to be involved in a continuous process of identifying ways to simplify work, right up until a story is complete.
My personal observation is that there are “seam words” in user stories that are important clues to unraveling complexity. If you see words such as and, or, both, or some, it means multiple things are happening in a story and it can be split into smaller, separate stories, creating more impactful and easily consumable increments. We should learn to recognize these common words and use them to reorganize and reduce the effort required to deliver value.
Smaller stories are needed to ensure that development work is rapid and trackable. Take the time to focus on breaking stories down into a more “digestible” size and you will be much more likely to estimate and complete your work.
Mitch Goldstein is presenting the session Finding the 'Seams': Making User Stories Smaller at the Agile Dev West 2017 conference, June 4–9 in Las Vegas, NV.
Thanks a lot!