As much as I like Call to Arms: Average Story Sizes of One Day, Jeffrey Davidson points out it is all about solution, rather than clearly describing the problem.

Here is a one line summary of the previous blog entry:

If your Agile project has average story sizes significantly larger than a day it could be messed up already, and courting some definition of failure. Try to change something to get closer to that one day average.

Here’s a stab at hitting the problem statement:

Lengthy stories drain developers, reduce a team ability to measure progress, put pressure on management to similarly lengthen iterations, and chip away at the stakeholders faith in the project team’s ability to hit milestones.

Large stories have a greater conceptual and maintenance costs. Developers have to perform mental gymnastics to be able to answer ‘where are you on this’ or ‘how much longer before your finish it’. As dev pairs rotate there is a transfer cost because the story is part complete. Pair rotation being good practice of course. Maybe you keep the same pair together for five days, eliminating the potential cost-saving because of ‘fresh thinking’ on the task at hand.

So lets say there is six weeks from ‘kick off’ to when the client wants to put the first version in production. You are at two weeks per iteration then that’s three iterations (we’ll ignore the fact you don’t often go live the day you finish). If your longer story size suggests shifting to three week iterations from two weeks, then that means there’s only going to be two iterations. That doesn’t feel right to me. It feels like it’s courting failure.

That last hints at the problems of waterfall: More than one eighteen-month phases for a project. There would be months of negotiations on what would go-live in phase 1, and an implicit further 18 month delay before anything would else would go live in the next phase. Customers of course wanted to negotiate their changes into the first phase. They didn’t want an 18 month delay so would negotiate hard. That was every project I was on from 1989 to 2000.

A worked example of breaking up a story

Here’s a story (feature injection style). It is for a mostly CRUD web app:

There is no reason whatsoever, that we could not split this into three actual stories (not tasks):

• story #132 can be about adding name/email fields to the page that already captures the complaint. Also the DB changes are in this one.
• story #133 can add validations to the two fields (mandatory, must contain an @)
• story #134 can be about a pending-status for the email unless a verification email results in a click to confirm.
• story #135 can be about the aesthetics of the fields. We’ll assume no pre existing non-functional-reqs (NFRs) citing CSS classes to use for new fields of certain types.

If we’re chasing Minimal Viable Product (MVP), and are going live five times a day as well as suffering 100 support requests an hour, then #132 followed by #133 then #134 then #135 going live separately, is maximum throughput (biz-val delivery into production). There is some flair for doing some of them in different orders, or tactically choosing to never do one or two of them.

If your business people/ customers (or their proxies) only want to sign off after #135, and/or are quite distant from the project/team room, then fix that. Organize some training if you have to.

Hearing complaints about big stories

The truth is that anyone in a dev a team can whistle-blow ‘stories are too large’.

Agile retrospectives, if everyone feels safe, are a place where honest reporting of ‘bad’ as well as ‘good’ aspects of the just-completed iteration happen. Maybe one senior person thinks the story sizes are just fine. Maybe more than one. If we’re doing agile right and safety is real, individual team members can indicate that story sizes are too big. That includes you Mr/Mrs introverted QA/Dev/UX. Use your three votes to effect change:

Some back history, and credits

I’ve been luckily enough to be at the elbow of Chris Matts when he started succinctly messaging around this stuff a decade ago. I have known Clarke Ching (first to cite Goldratt to me) on and off for fifteen years. With Jeffrey Davidson in recent years, I’m still hobnobbing with BAs who are good at explaining stuff.

I have a strong preference for eXtreme Programming (XP) over Scrum based on experiences. Nothing in this blog entry pertains to ‘Lean’. I really don’t want to get into a debate for “why not lean”. My end goal here is not to improve velocity. Note: Refer Jim Highsmith’s article on this, it is to maximize throughput.

We correctly consider “business value” when crafting a stream of stories for a project, and break into iterations for convenience. There’s no reason whatsoever why this has to be inextricably linked to large stories.

My best ever Agile (XP) project, had one-week iterations and average story sizes of 1.25 days. The technologies were hard (.Net 1.1 and WinForms), but we kicked ass in every other keep the throughput up. That project did estimate in ideal days, using finger-throws. It measured in actual days. Expect as case-study sooner or later.

These days ‘points’ are a more popular estimating model than days. I’m translating points (or gummy-bears or whatever) to days. I am doing this because everyone’s sizings are different. I also don’t care for S/M/L T-shirt sizes that are are complexity estimate and not time proportional.

On throughput per se. Throughput of ideas into production. Of concepts to cash. Robin Gibson used to have a video segment on this, that is momentarily missing from the web.

Lastly, I’d like to thank Jeffrey Davison for his help getting this message right, and link to his version of the same idea here, that he’s concurrently publishing.