The Structure and Size of Stories lies at the Heart of your Project’s Success

Matthew Caine Uncategorized 0 Comments

To help illustrate the importance this discipline let’s examine a case study. A large financial services company was running a large program using Agile techniques. When we say large, we mean multi-million-dollar, multi-year, multi-geographical and multi-vendor.

This is even today, not that common.

After getting through all the usual corporate red-tape, the project was ready to start delivering. The Agile approach also obligated the project team to fix the time in advance. They had done this by fixing the dates of the first 15 sprints.

Yet after only four sprints, the project was already in trouble. In fact 100% more budget would be required.

That may sound bad or more appropriately alarming, however we have to recognise Agile’s role in this early warning. Without it the project would probably have progressed as many large projects do, against a brick wall.

So why was the Project in Danger, so Quickly?

The symptoms that we observed included the following:

  • The project team did not know what was at risk when stories were pushed from Sprint to Sprint: Which stories were pushed out of scope, what had to be sacrificed?
  • There was no overall high-level plan which illustrated which benefits were to be worked on and when.
  • Requirements were poorly formulated e.g. “… should have X + Y” – does that mean both, optionally both, or just X or Y, or neither?
  • Everything was a must-have so there was no flexibility in the scope.
  • More than 50% of the sprint’s capacity was reserved for defects .
  • There was no front-end automated testing.
  • Of the 15 stories so far completed only two included API tests.
  • Product Owner engagement was poor, with a tendency towards less.

Let’s come up with the Level

Clearly the project team had correctly fixed the time and therefore cost. Yet because the scope was fixed only quality was flexibly which quite clearly was being subconsciously taken advantage of. A recipe for disaster.

Yet the ScrumMaster was delivering the sprint’s goal. With the disciplines of Scrum in-place, the product owner knew what needed to be delivered and fixed the scope for the sprint, which was given to team, which they delivered.

So at the team level everything looked good but at the project level we could easily see that it would take 100% longer to deliver the project than originally intended.

And we could see that only after four sprints.

Remember the plan was based on building new functionality not defects. If >50% of the capacity (time) is being used to fix defects the project is clearly going to take more than 100% of the original planned time to deliver.

So What is the Solution?

Smaller stories!

The existing stories were more like features or entire user-journeys. They had to be further sliced-and-diced to get a greater level of granularity (known as story-splitting). This would allow the project to take advantage of greater flexibility and apply prioritisation techniques such as MoSCoW. For example the original story/feature “to search” is clearly a must-have feature, but could be broken down into 30 or 40 individual stories of which may be only five are musts! Thus the project starts to eliminate gold-plating and delivers a fit-for-purpose solution.

The team also knows to focus on the Musts.

When the stories are smaller they can also get delivered earlier in the sprint. Those that are done earlier in the Sprint are the “Musts”. These can then be tested together with the product owner earlier in the Sprint to allow the product owner to build confidence in the software so that he or she can then demonstrate it (and ownership!) during the Sprint review, thus building product owner engagement.

Clearly smaller stories help testing. To judge if something is done is a whole lot easier. The acceptance criteria will also simpler. The fear of writing automation is also reduced.

The project management team can also demonstrates that they are in control. When things do not get done they have the granularity to understand what will not get delivered, which are the coulds and may be some shoulds. i.e. 5-10 of the extra features needed for the “search” feature will not get done. But that is ok, because the feature “to search” has been delivered.

Not Forgetting the Whole System

It is often the capacity of the team that is viewed as the project’s “bottleneck”. However, the preparation of stories is done before the team receives them. So focusing on allowing the team to process stories as effectively and efficiently as possible is key. So despite the theory of “systems thinking”, project members are always tempted to push requirements onto the team. This may make the demand funnel effective but it makes the entire system ineffective.

The true system’s thinker will recognise that there is more capacity in the “demand funnel” rather than in the team. There is after all no point in writing more and more stories if the team can’t deliver them. That will be waste.

So by focusing the resources within the demand funnel to create small stories that are just-in-time-delivered to the team, results in balanced “flow” throughout of the whole system.

But that is not enough either. After the team, we have integration. Surely that’s the place to start? Even if we deliver 100 stories ready for production, if they are not being used, isn’t it a potential waste of all that effort?

The Evidence Supporting Small Stories

This is in the realm of lean production. Let’s take a very simple exercise.

Take 100 letters, fold them, stuff them into an envelope, stamp and address them. How long does it take?

There are two tactics one is to fold 100 letters, stuff 100 letters, stamp 100 and address 100. We therefore, resolve the problem efficiently in batches of 100.

The second tactic is to do it one at a time.

Most of us today would assume that the 100-size batches are quicker, when in fact the 2nd tactic of 1-size batches is quicker. (Watch this video for an example).


Why is that? It is because we spend time actually organising our inventory making sure there is space, piles of envelopes do not fall over, we have to create space to work etc.

Not only that if there is an error we can quickly correct it when we are doing it one by one. If the envelope was just a fraction too small, we would have folded 100 sheets of paper, for nothing. Whereas we would have discovered that issue immediately with the small “story” size.

What get’s Measured, gets Done

At the Global Peter Drucker Forum in Vienna, Stephen Denning spoke about an organisation that produced 30 innovations per day. That organisation is Etsy.

And an “innovation” was a story. All they did was measure how many innovations they released daily to indicate how effective they were.

Surely this is an easy game to play – we just make stories smaller.

And that is precisely what we want!

What Next?

Need our Help?

Our half day workshops can help you solve your issues with this topic

Leave a Reply

Your email address will not be published. Required fields are marked *