How should you track small Incremental Pieces of Work?

Question

In my team, we often complete an MVP feature, i.e. MVP for Authentication. It has all the stuff it needs to be compliant and work, and meets the definition of done.

Then somewhere down the line, someone asks for something else, i.e. log out after x seconds. This is a single user story, which fits under the feature of 'Authentication'. I have usually by this point closed that feature and marked it as done, since it has met the definition of done. It doesn't seem right to add this new story under a closed feature.

So do I create a new feature for this one user story? How would you guys manage this small amount of incremental work in your backlog?

Answer 1

Use Tags or Labels for Functional Areas

Your team is misusing the term "feature." What you should be doing is treating the various aspects of your application domain (e.g. authentication) as components, functional areas, or concerns. This allows you to tag or label features, epics, stories, or tasks appropriately within an agile context.

By creating a separation of concerns within your backlog or tracking software, you avoid the overhead of creating new "features" with the same (or similar) names just to hold stories or tasks, and the anti-pattern of re-opening completed work items.

Answer 2

I would suggest your Definition of Done should apply to the story, not the feature. If your feature is Authentication then presumably that can never be completely done because there could always be a future defect or enhancement raised under the heading of authentication. Assign stories to features if you like but don't treat features as done.

Answer 3

When working "Agile" and "Lean" we should eliminate waste, e.g. reduce administration.

So do I create a new feature for this one user story? How would you guys manage this small amount of incremental work in your backlog?

If there is no reason to add more administration, you should not. This sounds like a "git commit" and a "Pull Request", and then merged and deployed to production. You have audit in the good commit message where you clarify why this was done.

Answer 4

I wouldn't get too caught-up here in etymology. This is a requested change to a general section, aspect or "feature" of the product, and as such it needs to be formally tracked. Such things can fall under the auspices of one "story" or maybe several ones. When people write the original version of a "story" they don't always get it just-right. I would capture the request somewhere, observe and sort out the requests as they come in, and in the near future "schedule a to-do work task" – call it what you will – to complete it.

I know of many teams which simply call these, "change requests."

Answer 5

For what purpose and value is this new story? Does it make it enhance the feature or give business value to customers? If the answers to these questions are positive, then the request can be treated as an enhancement.