Rethinking "Small"

Systems Thinking in the age of AI

Years ago I published a blog post called Rounding the Corners about how I applied Lean thinking (before I knew what it was) to mowing the lawn. A couple of years later, after acquiring a riding lawn mower, I published a second post called Systems Thinking in the Back Yard, in which I discussed how a new tool - the riding mower - affected how I thought about the process of mowing the lawn and how some previous efficiencies were no longer necessary.

That same experience returned recently when I was implementing a new feature to import a new type of file.

---

I first learned about the INVEST approach to user stories from Bill Wake over 20 years ago. In that approach, when writing stories you apply these criteria to determine if the story is clear, and as small as it could be:

• I – Independent

• N – Negotiable

• V – Valuable

• E – Estimable

• S – Small

• T – Testable

When writing stories and coaching others to write them, we all put a ton of emphasis on Small, because that enabled us to move faster and deliver partial value sooner. This was a core tenet of XP and any other approach that brought in the practice of user stories. I’ve spoken extensively on the topic and wrote “How Thin is Thin?” An Example of Effective Story Slicing back in 2014.

I argued that small user stories improve the flow of work through a team, like sand through a funnel vs. rocks or gravel:

This approach has worked extremely well (if you’ll pardon the XP pun) for me and teams that I’ve coached or led that have used it.

This recent experience, though, brought me back to the notion that the tools you use can affect how you structure your work.

I was reviewing a customer requirement to import a new type of file into the product on which I’m working. Another developer and I looked at it and realized that this single Jira ticket was really about a dozen user stories, using my “thin slice” approach.

Each story would require some conversation about its value and what would mean “done” for it. Each would require some development work, which would then be reviewed by the developers. Each would then require testing by our testers who are located in the UK, 5 hours ahead of us.

So, each story would likely have taken a full day to be completed. That doesn’t sound like much, but if there are 12 of them, that’s more than two weeks of elapsed time to deliver the full functionality.

By the time this ticket had reached the development team, we had been using AI to good effect helping generate code in some cases and especially tests. I decided to feed the ticket’s requirements in to the LLM I was using (Claude Opus 4.7), and have it generate a plan for delivering support for this new file type.

As is my approach with LLMs, I had a back & forth conversation with it and settled on what looked like a solid plan to deliver all of the functionality. I asked the Product Owner a couple of questions as well, which helped tweak the plan.

Claude then generated the code for the whole ticket, with tests, in 15 minutes. We had some more back & forth working on details of the file format and I did extensive manual testing with sample files to be processed.

We completed and delivered the full ticket to testing in 90 minutes. It was validated by the testers the next morning. It took less than 1 day to deliver the whole thing, rather than the 12 if we had used the more traditional story splitting approach.

If I go back to Systems Thinking in the Back Yard, the tool, a riding mower, made “rework” cheap, so adding some made the overall process more efficient.

In this case, the tool, Claude Opus, made the process of delivering a story cheaper, so working on one large story rather than many small ones was more efficient than doing the work by hand. This, of course, challenges what we in the XP community have been saying for decades.

Silver Bullet?

I will say, though, that the requirement implemented in this case was relatively straightforward. Here’s the file format definition. Use the same process as importing MS Word files. The UI consists of just a dialog to choose the file and then the main UI showing the data after import.

There’s another example like this in the same codebase where I was able to replace the old Javascript library used to perform the MS Word import with a Rust version. Again, we had known inputs and outputs and an existing process into which the new version was “plugged”. That took about 2 days to implement with Claude, since I’ve written nothing more than “Hello World” in Rust.

So, does this mean that we should go back to large stories with reams of descriptive requirements in Jira tickets?

Well, as always, it depends.

As I just stated, there are cases where I do indeed believe we can do that. I also believe that there are many cases where we can’t, and smaller stories work better in terms of flow within the team.

If we’re working on something brand new that the stakeholders and consumers of the work haven’t seen before, I’d still want to get early feedback on smaller parts of the work in order to better understand the problem being solved or the capability being enabled.

Every software requirement has assumptions baked in, and the larger the requirement the more the assumptions. With the examples I gave above, there were existing patterns (and code) to follow and the inputs & outputs were known and deterministic. If that’s the case, then I think you can indeed deliver bigger chunks of work quickly with the aid of LLMs.

If, however, there are many unknowns and we aren’t really sure what should be delivered, then doing something small and getting feedback still wins.

And, as always, my opinion on this may change at any time!