At the beginning of a project, writing things up as user stories is a great way of getting a handle on the functionality of a project. Stories at this stage tend be conceived and written relatively broadly, to cover a bucket of functionality. A couple of examples from my current project:

  • As a sales person, I want to be notified if a job above a certain price threshold has been created, so I can offer the user a discount.
  • As a user, I want to be able to pay for my job using a credit card.

And that's fine.

Toward the end of a project, though, it's quite common for omissions to be spotted. I'm not talking about bugs but instead minor things that no-one considered during development but came to light through user testing or checking more complex usage scenarios. Again, a couple of examples from my current project:

  • As a user, I want to see a spinner during long uploads so that I'm aware the site is still active.
  • As a user, I want to be taken straight to my most recent job when entering the site through the link in the "job complete" email.

These are tiny in terms of both scoping and effort compared with the original, broad users stories. However, if one's manager wishes to track the project comprehensively, they will need to be written down and detailed as individual items. And rightly so: if they're important, they need to be recorded and not forgotten.

This irks me on several levels. These small stories clutter up a project and make it harder to track. The time and effort involved in writing up these tiny stories seems disproportionately high compared with the effort of just doing them.

Is this something other developers have found, or are we approaching the concept of user stories? Are there any good methods for dealing with the ever-shrinking story size, or is it something you just have to suck up?

EDIT: This is not about avoiding late user stories or trying to restrict scope creep. My aim is to embrace additions, scope and track them, but to reduce the effort and confusion that results from their much more granular nature compared to early-project stories. Early in a project you might write one story and have it split into 3-4 tasks taking a day or two each. Late on, we find ourselves writing a story with one task that might take an hour or two. So to scope a weeks' work we might end up writing 15 user stories instead of one. This is time consuming, and leave the project board a confusing mess.

  • Possible duplicate of How to manage scope creep?
    – gnat
    Apr 27, 2017 at 9:25
  • @gnat I would say this is a quite distinct problem from scope creep. Rather than additional features, this is about small details in existing features which everyone agrees are necessary but which have been missed. It's also about how best to track them with minimal effort, rather an avoiding them. Do you feel it needs an edit to make this distinction clearer?
    – Bob Tway
    Apr 27, 2017 at 9:28
  • 2
    It is natural that you learn new things and get new ideas during the project, this is one of the reasons for agile and iterative processes in the first place. You just need to keep prioritizing. You shouldn't think of user stories as "cluttering up you project" - they are your project.
    – JacquesB
    Apr 27, 2017 at 9:33
  • 2
    @MattThrower: If it is a costly and cumbersome process to define and prioritize a simple user story, then you have to streamline the process. What is the difficulties you face?
    – JacquesB
    Apr 27, 2017 at 9:36
  • 4
    @MattThrower: to my experience, the smaller the feature request, the better it can be managed. We are using an issue tracker/ticket system for managing them (in our case Redmine). Writing them down, priotizing them, assigning them to a team member, managing the status (or just leaving the request there for not forgetting it later) etc is very efficient with such a tool.
    – Doc Brown
    Apr 27, 2017 at 9:57

1 Answer 1


A small user story should not be a problem. If your process adds a lot of overhead to managing user stories, you need to look into your process or tools to streamline it. In a modern issue tracking system, creating a user story should only be a few clicks.

Too much administrative overhead may even be a cause for the issue you see. If it is painful to create and manage user stories, you encourage writing few large user stories rather than a larger number of more specific user stories, which means more details will be overlooked.

The time and effort involved in writing up these tiny stories seems disproportionately high compared with the effort of just doing them.

Beware! If it takes a lot of time and effort to write up "small" user stories, it indicates one of two things:

  • The user stories are not actually small, but only looks small until you start thinking the scenarios through.
  • You are not really sure what the requirements actually is.

In both cases, writing the user story is an important process of clarification. Maybe changing the code is simpler than clarifying the requirements, but if the requirements are unclear you are surely going to write the wrong code, which is a lot of wasted effort and added risk.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.