Much has been written about the importance of working in short cycles, and the need to cut and slice your stories to small pieces that will fit inside of a single sprint. I’m not going to repeat all this.

What I would like to write about is something that might seem counter intuitive at first and it goes like this:

The bigger and larger the project you are working on, the smaller your stories should be sliced.

Yes, if you are inside this huge enterprise working on this big and complex project along with several other teams, your stories should be extremely small.

How small? about a day or 2 worth of work.

That’s the only way to achieve a constant flow of working software. Everything else you are trying to do will become much harder unless your stories are that small.

Let’s go over an example:

Lets say that you have a few teams, and since we are talking about a real project (and not the ideal everything is just the way we like it) the work of the various team is not totally independent. Its not that all features requires integration between ALL teams, but in many cases features spans two teams and sometimes more. So the teams have decided that they need to catch up at least once a week and make sure everything is working ok together.

Sounds reasonable .

So, for Tuesday (that’s the day the team chose for integration), all the team gets ready. They finish all open issues, and make sure all the feature they worked on actually work. They start the integration but Oops, something goes wrong and something doesn’t seem to be working. After a short investigation, they locate the suspected area, (yes its in Team A code), but in order to find the cause, fix it, the team needs to go deeper. Naturally the other teams not wanting to waste time, start to work on new stuff while waiting for Team A to fix this. After a day or 2 Team A finds and fix the problem, but now there’s a problem, the other teams moved on. Their current state is not good to do integration, so they wait till Tuesday to try again.

And guess what’s happen on Tuesday? Right, since they try to integrate more work, the chances that something breaks is even higher. and indeed not everything is working,  only this time its team B. And in the following Tuesday its team C and so it goes on until someone notices and call for a stop.

This scenario, lies at the roots of the familiar “code freeze” mechanism. Since, its hard to do proper integration while all teams are working in the back ground. We need them to stop, and only immediate issues found in integration and other found bugs. The only problem is that for the teams being in code freeze feels very wasteful. Most managements will only tolerate this state is short, and doesn’t happen too often. Once the Code freeze is long, everyone will feel the pressure to move on to new stuff. Which in most cases only makes the freeze longer and waste even more time and effort.

So that’s not a good idea, what else can we do?

well another option is use source branches – but Ill save you the entire rant on those – these are not a good option.

The Benefit of Small Stories

The effective solution for this, is working on smaller stories. if you manage to get your stories small enough, you can do the integration more often, instead of once per week, maybe 3-4 times a week. And even when things do break during integration, chances are that since we are working on such small items, it wont take so long to investigate and fix. if it doesn’t take too long, so the other team maybe will be able to wait a little until we do manage to locate and fix. And even if it does takes more time (maybe a day or two). Once this get resolve we can try integrating it again almost immediately.

Remember principles 1&3:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Image by brgfx on freepik.com