Size Matters in Agile

Size Matters in Agile

Measuring Tape

Recently, I have been working with organisations that have made things difficult for themselves by having teams that are too big, user stories that are too small or a combination of both.

While there are many differing opinions on the ideal size of either one of those things, my own preferences (on average) are the following:

  • A good agile team is seven, plus or minus two
  • A good story size is about two days to one week’s effort
  • A good task is between two and 16 hours

So, a team that is too big is:

  • 10 or more people

And a story that is too small is:

  • Around one day’s effort or less as a rule of thumb

Next, let’s look at some of the issues that we might encounter if we consistently work with teams that are overly big and/or user stories that are very small.

When the Team Is Too Big

The effectiveness of team communication decreases when the team is too large. There has been lots of research in this area that can give a lot more detail than this post, so here I just want to give a few examples, especially around ceremonies.

Many people suffer, to some extent, from Glossophobia, which is a fear of public speaking. If we have big teams, our ceremonies can feel like public speaking, especially if there are also people from outside the team present.  

Some who will have very good points to contribute may not and we will lose their valuable input. In agile, we value face-to-face communication because it is very effective, so we shouldn’t create situations where people are anxious about speaking.

Another thing to consider is that all ceremonies will take longer or become rushed as teams become bigger. I have witnessed one team that was so big that their daily scrum took over 30 minutes. The Scrum Master’s answer to this was to limit everyone to essentially saying: “Yesterday I worked on Story X; today, I will continue to work on Story X.”

Anyone attempting to talk about anything else at all was advised to have a discussion later and all effective communication was lost.

Likewise, estimating and planning sessions, retrospectives and reviews are similarly impacted.

When User Stories Are Too Small

In his book “User Stories Applied,” Mike Cohn suggests that we should use the INVEST acronym to help us write good user stories. The principle is that stories should be:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

Let’s take each one and examine some of the challenges that we might face if we try to follow Mike’s guidance when we have very small stories.

If our stories are too small, it can be difficult for them to be independent, which leads to planning and prioritization problems. In fact, having too many dependencies makes it difficult to adhere to the majority of the other principles, because to satisfy them, we would need to consider the full dependency chain.

For example, if the related stories are not yet developed, is the user story still as valuable? Can it be estimated independently? Can it be effectively tested in isolation?  

Very small stories are difficult to negotiate as they deal in the lower level detail. The acceptance criteria are no longer reminding us to have future conversations, but instead make us feel like no conversation is required. We miss a chance to have conversations and hear other viewpoints that could lead to a higher quality product.

It is not unfeasible that a small story can be very valuable by itself, but often overly small stories are of little value until their related stories are done.

I do concede that we should get more accurate estimates with smaller stories, but with an increased number of stories that contain lots of detail, those estimating sessions will be onerous and I would question if the increased accuracy would be worth this extra effort. When we estimate using story points, we are not looking for precision, just an idea of relative size.

Good user stories should be small but they shouldn’t be micro. They are small enough to be done in a sprint, but not so small that they can be done in a few hours.  

As previously mentioned, it can become difficult to make small interdependent stories testable and it often seems more efficient for testers to group these together, which suggests they could have been one story to begin with.

It is important to note that I’m not saying that we can never have a very small story, just that it should not be the norm. If we see a user story as normally being two days or more effort, it still leaves us some scope to break those stories down into meaningful tasks in a sprint planning session, discuss them in detail and estimate in hours.

When Teams Are Too Big and User Stories, Too Small

If we have a larger team, which has a larger capacity, we can do lots more small stories. If we double our team size, we will probably just about double the number of stories we aim to do. This directly results in an increased overhead being applied to almost everything we do.

It is fairly easy to imagine how our ceremonies would become even more onerous when we add more and more detailed stories for consideration. However, there are some other key areas that are now less effective:

If we favour the technique of capacity planning (I think we should), we will find that it is very difficult to break small stories into meaningful tasks as they are task size already. What’s more, you would probably have hundreds of them. These things taken together usually means that the technique is unworkable.

In Summary

I continue to work with teams who struggle with these issues in one way or another. While I don’t think we need hard-and-fast rules for every user story, I do think we should be watchful for what could be described as an anti-patterns developing in our organisations or teams.

I would love to hear what you think and if you have any further examples where team or user story size matters; please share in the comments below.


David Cassidy is an Agile Coach with over 20 years’ experience in the software industry.

Learn More
comments powered by Disqus