Your stories are too big

TL;DR: Many teams ask for larger stories because they do not see how to slice the work into smaller chunks. When you give into this anti-pattern you are making developers work harder, and possibly decreasing the value of what you deliver. Write smaller stories and your team will be both happier and more productive. 

One of the most common problems I see on Agile & Scrum teams is the stories are too large. I once had a project where a user story had over 40 acceptance criteria and took over 2 months to complete development, not including the time it took to write the story, test it, or fix what was broken. Six months later, I joined a project where most stories were estimated at 5 points, and the average 5-point story took 20+ business days to complete. This seems ridiculous to me. Stories should never be this big! Which of course begs the question, “How big should stories be?”

One of my trusted advisors, Paul Hammant has the same problem with story sizing. I prompted him to write “Call to Arms: Average Story Sizes of One Day.” The problem with his post is discusses how to fix teams when developers takes too long without stating why stories should only take one day. I finally told him, “I like what you wrote, but it’s the second half of a book. Write the first half of the book. Explain why this is important. Then I can comment on your ideas, we can get some feedback, and finally start to make a real difference.”

It’s only taken a few months, but Paul finally agreed to write the first half of his Call to Arms. In the course of badgering him, he talked me into writing a complimentary post on the same issue from a BA perspective. Paul’s new post is called Smaller Stories.

Here’s Paul’s thesis: 

Developers are at their best when they can complete the work at hand in about one day. 


Here’s my argument for Paul’s position:

To start, you need to understand how I view teams and getting work done. My primary reference for today’s post is from Eliyahu Goldratt’s Theory of Constraints. For those who are not familiar with his work (Shame on you! Go read The Goal.), one of the axioms in ToC is the first thing you should optimize is the area with the biggest constraint. If you spend time optimizing anything besides your biggest constraint, you are wasting your effort. For a great visual example, check out this demonstration of ToC.

Using Goldratt’s logic, I previously argued developers are the biggest constraint on a software development team. See my post Is Agile Just for Developers for more details. Taking ToC and acknowledging devs and the primary constraint, it makes sense we write stories to optimize for them. But why just one day?

I have a few reasons and they are all about the cost-benefit ratio of big versus small stories. First, despite what their non-technical friends think, developers are human and need the same thing as the rest of us. One of those things is a sense of accomplishment and appreciation. All of us need this. And we get this by overcoming obstacles and completing tasks. Finishing a story, by definition, gives a sense of accomplishment. Even when developers make fun of the story and how simple or short or easy or …, they still feel accomplishment when the story is complete. Everyone likes being able to say “I built this.” Short stories give good feelings more often than big stories.

My second point is the flip side of that, I have worked with developers with large, looming stories that take many weeks or months to finish. These folks are f-r-u-s-t-r-a-t-e-d. Even after the work is done they talk about how painful the experience was, often for more months than they worked on the story. Big stories give pain often than small stories.

I know this is touchy-feely, which many people and teams avoid, but I think it is important because it directly relates to the morale of the team. I believe Business Analysts should shepherd team morale and protect it whenever possible.

Third, larger stories are just that, bigger. And in being bigger, it is easy for Business Analysts to more likely to have missed acceptance criteria, contradictions, and implied requirements within the stories. This point isn’t about the developers, it’s about the input to the developers. Larger stories are more likely to be confusing, and this makes development much more difficult.

Fourth, the larger the story, the more developers (and other team members) have to keep in their head. There are conceptual costs to developing and maintaining mental models of the goals, business domain, code they are working in, and what they are building. Keeping large mental models for a long period of time adds extra effort to what the developer must accomplishment. Simply put, smaller stories are easier to understand. What’s easier to understand is easier to code.

Fifth, developers have maintenance costs of keeping things in their head over night, over the weekend, over the latest showing of Episode II: Attack of the Clones, over lunch, whatever.  As much as this sounds a bit humorous (and who would want to see that movie again?), it’s not. Developers, as much as they may act like machines, are not. They don’t have instant recall. In addition to building and updating the mental models above, they need to come in and figure out where they left off.

Good developers focus on, “What is the very next thing I need to do in order to make this work?” When stories are too large, then the details and variations of what must and could be coded overwhelm the very real question of what needs to be done next. Like a transition cost when you are doing too many things at one time, this cost is real and adds unnecessary effort to building solutions. Big stories make it difficult to know what needs to be done next.

Sixth, the combined effects of larger stories adds up and eventually impacts the amount of work developers can complete. When stories are too large, and the impacts of above items are all affecting the developer, it makes sense the work will take a little bit longer. The immediate impact of a single large story probably won’t hurt a project. On the other hand, the difference between a bunch of large stories and the same work broken into many small stories will add up to measurable difference. Here’s an (exaggerated?) example of what I’m talking about:

Little Stories Save Time

Again, I don’t have any supporting proof, but I believe a pattern of small, easier to finish stories results in work being completed a bit faster. If you work a bit faster on 10 small stories, or 40, or 600, you will save measurable time over working on fewer large stories. Small stories allow more work to get done.

Seven, it’s easier to control and change scope for value when you write smaller stories. We all know the benefit of Agile is the ability to change direction. When I deliver in smaller increments of work and show my progress to clients, I get more feedback.

Also, when I write smaller stories it is easier to put the most valuable stories first. It doesn’t happen all the time, but sometimes they say, “This is good enough for now. You can stop work on this and start working on a different feature.” The impact of discovering you don’t need to do the last week of work in a five-week story series means you avoided wasting resources. I tried to capture this in the following chart:

Focusing on Valuable Stories Reduces Work Required

Jim Highsmith often talks to executives how Agile impacts value.

Rather than asking, “Did we implement all the requirements?” the question should be “Can we release this product now?” I’ve known projects that were deemed releasable with 20-30% of the originally anticipated functionality—and the customers were delighted. They got their fundamental needs met—very fast!

Writing in smaller chunks allows the team to respond to change, whether it’s a new direction or stopping the current plan. Smaller stories may reduce the amount of work needed.


What are the costs to small stories?

Part of me doesn’t like small stories; the part that has to write them. Maybe I’m wrong, but it feels like I’m doing more work when I write more stories. I cover the same amount of functionality, but writing 40 or 60% more stories feels like a lot of overhead. I believe the effort to write smaller, more independent stories is worthwhile because it benefits the developers more than it costs me. And I suffer from some of the same issues listed above, so it may not be much more effort on my part.

Also, writing smaller stories may lead you to a mess of dependencies. It is frustrating for a team to have one story block the work of other stories. It is dangerous to do too much work in the same area of the code simultaneously. Slicing work into small stories means you need to plan for how the work will be sequenced because some stories will naturally build on the result of another story.

A peer and friend, Inger Dickson, CBAP tells me this is a false argument against a good practice.

I firmly, with a flag-waving fervor, do not believe a de facto cost of small stories is dependence. Planning is important, as is sequencing, but accepting dependence as a cost of small stories goes against the INVEST model, which is the equivalent of the heart that pushes requirements through my circulatory system. This is why finding the RIGHT small stories is hard!

Lastly, writing small stories without understanding the scope may lead you down the wrong path. Writing stories in isolation from each other and the scope can give everyone a false confidence. If you do not understand the domain or approach, writing small stories can lead to big costs and add work and rework for the team. It’s similar to blazing a new trail without a compass, you think you are making good progress without understanding you are going in the wrong direction. The result is you will have to backtrack, remove the unnecessary work you added, and then start over. This is allowed in Agile and some of this is to be expected. But as a Business Analyst, I feel bad when I contribute to this by not understanding and communicating the vision properly in the first place.


Here are my conclusions:

When we write stories too big, we make our team and all the downstream recipients of our products work more. The costs for this pattern are too great. Writing one 20-day story will never get you more than 20-days of output. Writing the same functionality as 5 or 10 or 20 stories will get you the the same output, with a happier team, and quite possibly finish in less than 20 days.

My conclusion is Business Analysts can do better. When BAs write stories that are too big, we impede progress. We need to help our teams do better. We need to give our teams smaller chunks of work. As a BA, you gave an unstated promise to your team, a promise to give stories providing meaningful, valuable, deliverable work. Go out there, write smaller stories, and help your team accomplish more.

  1. I cannot prove Paul is right and one-day stories are a magic bullet dev teams should be focused upon. When I talk to him about this everything makes sense to me, but we are missing empirical proof. My gut tells me that if your developers cannot finish at least two or three stories per work week, then you have a “smell” and should start troubleshooting.
  2. I’m not a developer. I am very hesitant to telling a big part of my team how they should be getting their job done. I have not done the job and I do not grok all of what devs do. For me to tell them they must follow a potentially arbitrary rule is too presumptuous for me.
  3. If you’re working in a Scrum or Agile or Kanban team where you break stories into tasks, then I am talking about this smaller unit. The importance here is how you deliberately size the work you are about to begin.
  4. Bill Wake’s INVEST, mentioned by Inger above, is the go-to guidelines for user stories. I have found teams with larger stories are typically breaking multiple issues besides being too large or inestimable. If your team is breaking these guidelines, figure out how to fix the problem. Retrospectives are a good place to start.
  5. Paul’s post has a bunch of statements about different estimating techniques and his preferences. Recent online discussions are arguing for abandoning estimates. Personally, I don’t care how you estimate. The point (no pun intended) is the size of your ‘work’, not the estimation style you use or don’t use. By the way, estimating is valuable, even if the answer are not.
  6. I also think we stories should be a consistent size, but that’s a different argument and a future post.
  7. I did not discuss benefits of small stories on writing, testing, or validating. I leave this for you to include within your comments below.


  1. Stephanie   •  

    I have currently been arguing this exact conversation with my team. If you don’t understand the work clearly enough to break it down from a 20 day story then we are NOT ready to start coding. In the famous analogy “You eat the elephant one bite at a time.” We need to get better at breaking it down to bite sized work slices we can COMPLETE.
    I agree that people need to feel a sense of completion and accomplishment. You can break the stories down without losing sight of what the final product is going to look like.
    I am interested to read ToC and INVEST and see if they help to shape the success of my teams. I am also looking forward to more information on this topic and this thread.

  2. Julie   •  

    What makes writing a user story so different than describing requirements? I’ve worked in both a waterfall environment (before it was ever even called a waterfall environment) and in an Agile environment. I found user stories to be cumbersome, at best. Maybe it’s just me, but in my personal opinion, less is more. Plainly stating, step by step, what needs to be accomplished makes so much more sense to me. Sometimes I think the term “user story” gets taken too literally, and as a result, becomes verbose, leaving the reader trying to figure out where to begin.

    • D. Paul Sims   •  

      Julie, technical jargon often gets in the way of interpreting requirements. User stories are written in the language of business users so that the users can participate in discussions with agile teams. Stories are a reminder for agile team members to have a conversation with users (and other stakeholders, e.g., sponsors, partners, even insiders) about what the story means to users. Stories capture the role, goal (task), and business value (significance of the task) from a user’s perspective. For example, “As a ‘Shopper’ (role), I want to ‘establish an account that remembers shipping and billing information’ (goal) so that ‘I can save time when placing future orders’ (value).” The value is important because the agile team’s product owner uses value to prioritize stories in the team’s backlog. Value also tells team members why the work they are doing is important.

  3. Scott Warren   •  

    Well written! It can be a really fine line between a story that too big and a story that just right.

    When I moved jobs, it was really hard to convince the teams at the new office that smaller was indeed better. The number one complaint was the stories overlapped or were too small…This was never the case, the stories had in fact drawn out a number of dependencies within the existing code, not to mention the code that was yet to be written to complete the feature. It made the team think about the best path to take in order to achieve the sprints goal. This to me was a win and a great example of what breaking up a feature into smaller stories.

    In the past the team would run into all kinds of blockers mid sprint and find themselves stepping on each other toes all too often…all because they were thinking of the feature as one big story, then going in all gung-ho and not thinking how that feature ties into the each individual component within the application itself. It felt dirty and stressful.

    It wasn’t an easy transition over to the new technique, and it certainly wasn’t a quick one. We did however get there in the end. This was made possible through seeing great results. The developers were able to keep on task, the QA team were happy that they finally had structured testable stories. Overall, the product was in a much better shape.

    Goes without saying – This change has been a welcome one.

  4. Jeffrey   •     Author

    FYI, a few people have commented on this article in the Agile Coaching group on LinkedIn. It’s a private group, so you have to be a member to read & participate in the discussions, but this group would be worth your time.

    @Julie, I am hoping more people will jump in and provide a response to your questions. I don’t want to hog the conversation.

    • Julie   •  

      Jeff, did I respond in the wrong area? Forgive my ignorance, but I’m having a bit of trouble trying to figure out if I replied in the correct area or not.

      About user stories, this seems to be a sticking point during my current job search. While I’ve never written a user story, per se, I’ve definately prepared requirements. Why are todays employers so hung up on whether or not someone has actually written a user story or a use case? They are simply requirements written in a different format, and certainly they are not something that I could not do if I held a position where I was required to do so.

      Are there so many of us looking for work that whether or not you’ve written a user story becomes a reason to over look someone as a candidate?

  5. D. Paul Sims   •  

    Jeffrey asked me to re-post the comment that I added to the LinkedIn Agile Coaching group.

    I said, “While we’re on this topic, I thought I’d add references to my favorite articles on splitting stories (in no particular order). They include Richard Lawrence’s, Joe Rainberger’s, William Wake’s, and James Grenning’s (Story Weight Reduction Toolkit). What are your favorite ways to split stories?”

  6. @RiczWest   •  

    G+, Chris Kemp: Your stories are too big One of the most com­mon prob­lems on #Agile & #Scrum teams

Comments are closed.