How Transaction Costs Influence Story Size

Of all the aspects of the INVEST principle, I think the attribute that software developers have the most influence over is S. Small

Small stories have huge benefits. We can control what gets built with much more granularity.  Less scope means fewer requirements for the team to understand. Less for the end user to understand. Less code to for the developer to change. Less code to test. Less code to release and maintain.

Less risk.

Ron Jeffries recently tweeted a short video on story slicing that triggered a question in my mind about why engineers resist small stories. As I thought about it more, connections formed to Don Reinertsen’s work in  Managing the Design Factory and Principles of Product Development Flow. There he describes the “transaction cost” of an activity. The transaction cost is the cost/time of everything needed to execute an activity.

If we put this in the context of releasing software, this may include the time to build, test, and deploy an application. If those tasks are manual and time consuming, human nature is to perform these tasks less often.

Transaction costs follow a U-curve, where performing an activity may be prohibitively expensive if the size of the activity is too small or too big.  For example, think about a story for user account registration. It would be costly to create a story for each word in the form text. Likewise, the cost of a story would be huge if it includes creating the form, validating it, sending notifications, account activation, error handling, and so on.

So, back to Ron’s video and push for thinly sliced stories. I posed the question about what to do when developers resist small stories. To dig into that, we need to understand why developers resist small stories.

A common argument that I hear against small stories is that it’s not efficient to work that way. We developers are always looking to maximize the work not done 🙂

This can be a problem, because the true work for a story includes everything to get it production ready. Writing each story. Developing each story. Code reviewing each story. Testing each story.

That is the transaction cost of a story.

Driving down those costs drives down the resistance from the developers. There are lots of ways to reduce these costs. We can pair program to eliminate the out-of-band code review. Use TDD and automated acceptance testing to build quality in from the start. Create an automated build and deploy pipeline to continuously deliver stories.

As we reduce the overhead of each story, we can slice stories thinner and thinner.

But wait, there’s more!

As Bill Caputo rightfully pointed out, big “efficient” stories include a lot more work than may be necessary. Thinking back about an account registration story, we may put account registration and account activation into the same story. That builds in an assumption that we have to activate accounts – which we may not.

Not splitting stories means we may efficiently build something we don’t even need. Peter Drucker famously said –

There is nothing so useless as doing efficiently that which should not be done at all.

Addendum – Be careful what you measure

Another reason developers may resist breaking things down into small deliverables is how they’re measured.

In most scrum worlds, a team is being measured based on velocity. Small stories are fewer story points, thus lower velocity.

Uh oh, let’s make bigger stories and drive higher velocity.

To address this problem, Ron suggested giving “credit” for stories completed rather than story points completed. This encourages splitting large stories into thin stories with little pieces of the overall functionality.

What Do DevOps, Test Automation, and Test Metrics Have in Common?

This is a guest post by Limor Wainstein Agile testing is a method of testing software that follows the twelve principles of Agile software development. An important objective in Agile is frequently releasing high-quality software regularly, and automating tests is one of the main practices that achieves this aim through faster testing efforts. DevOps is […]

Loss Aversion and Tech Debt

Humans are loss-adverse. We place an irrationally high value on losing something over gaining an identical item. So for example, I’d be more upset about losing $10 than the happiness I’d feel by gaining $10. If I buy a meal and hate it, I’ll likely finish it anyway. In general, people would rather gamble on […]

On Hiring Techies – Evaluate Potential, Not Accomplishments

This is a part of a series on Hiring Techies. Evaluate Potential, Not Accomplishments I don’t spend a ton of time reading resumes. Depending on the position we’re hiring for, I may look for a few critical skills but I’m mainly looking for themes that tell me that the candidate has a passion for technology. […]

On Hiring Techies – Coding Challenge

This is a part of a series on Hiring Techies. Coding Challenge Of course, if I’m evaluating a candidate to join my team I want to ensure that they know what they’re talking about. There are many ways to do this. Some people slam a candidate with technical questions for hours. Some people choose to […]