As an agile coach, my work revolves around helping teams learn and improve. When I meet a team for the first time, they will frequently be preparing to undergo an agile transformation. Sometimes, having transformed recently, they seek additional re-tooling and advanced learning. Some clients are considering expanding or scaling agility in the enterprise.
Entering as an ‘outsider’ can be tough, especially in an environment that is experiencing maturity pains. Part of the coaching experience is to keep teams focused on the underlying principles of agile, lean, system thinking and economic perspectives. The rest is getting the organization moving in the right direction by getting quick, stackable wins.
Agile coaches are famous for setting rather high ambitions for ourselves and the teams we work with. To be successful in creating high-performing teams, we must take a stark and candid look at whether we are embracing the ideas of minimizing batch size. In agile terms, this means that we must create and execute the smallest possible increments of value.
The INVEST Mnemonic as a Guide
Minimizing batch size is entirely consistent with the legendary INVEST mnemonic. This mnemonic reminds us that our user stories need to be independent, negotiable, valuable, estimable, small and testable. The ‘small’ part and the ‘estimable’ part of INVEST can be the most difficult to adhere.
Iterative elaboration of stories and a 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.
How does smallness help?
Back in the day, there were a few classic works that were considered required reading long before agile: Knuth, Deming, Brooks, Hofstadter, Kidder, Kernighan & Ritchie.
One other required work was a short essay by a Hungarian mathematician, George Pólya, called “How to Solve It,” which I highly recommend. This essay captured the essence of iteration and elaboration to solve complex problems.
Also, there is a helpful list of heuristics that are intended to be employed, including ‘decomposition.' This heuristic is the principle that establishes 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. We can apply this paradigm to the entire value stream process and the overall cultural improvement of an organization.
Small improvements and changes are easier to support and complete.
How is smallness achieved?
The act of decomposition is something that must be a collaborative and iterative process. The entire team needs to be involved in a continuous process of identifying ways to simplify work, and this occurs right up until a story is complete.
My observation is that there are 'seam words' in user stories that are important clues in unraveling the complexity of stories and ensuring they are broken down to impactful and consumable increments. We should learn to recognize these common words and use them to reorganize and reduce the units of effort required to deliver value.
Certain words in your stories are indicators for areas to breakdown. Do you see the words ‘and,’ ‘or,’ ‘both,’ ‘certain,’ or ‘some’? If so, you might be looking at an easy way to break your story down for more efficient consumption.
I will present this topic at the Pittsburgh Agile Meetup on Wednesday, August 14 at the Engineers' Society of Western Pennsylvania, 337 Fourth Ave in Pittsburgh. RSVP your attendance. Here is a preview of my presentation.
Smaller stories are needed to ensure that development work is rapid and trackable. Take the time to focus on breaking stories down to a ‘digestible’ size, and you will be much more likely to estimate and complete your work.
Join Mitch Goldstein to learn how to "Make User Stories Smaller" at the
PittAgile August 2017 Meetup
