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.