How to avoid or amalgamate tiny late-project user stories?

Question

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.

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.