My team is using scrum and TFS to manage a new software project. Some members of the team want to solve a problem in a rather unusual way. I need to know if anyone has dealt with something similar. (This is partly a scrum/project mgt question, and partly TFS because if TFS makes one approach much easier than another, that will influence the decision.)
There are parts of this software system that have not yet been specified in any manner—not via User Stories, Acceptance Criteria, tests or anything. They are to some extent "corner cases" or error-handling cases. Yet the software already behaves in a particular way when these cases are encountered. (This may be by displaying a generic error message or going down a common path to some resolution.) This situation exists because the software is designed to be error-tolerant.
Team members want to define and thereby lock down the unspecified behavior, so it won't change. If it does change—and in particular if it changes for the worse (e.g., crashing instead of displaying a generic error message), they want to catch that.
But they are proposing to do this by writing tests or Acceptance Criteria that match what the system already does in the corner cases. My position is that any currently-unspecified behavior that we want to keep stable should be defined via new User Stories first, not via Acceptance Criteria or tests. What is the proper scrum/TFS way to document and lock down as-yet-unspecified behavior in an existing body of software (preferably with the least effort)?
It is something that the users of the system will benefit from, so do it as a user story:
As a user I want the product to be stable and not crash when a specific behaviour occurs so that I have a good user experience
To satisfy this user story you may well write a technical task that leads to tests that simply match the existing edge case.
Why bother making it a user story? Well this work item will need to be prioritised against other backlog items, including new functionality. By creating a user story we allow it to be prioritised using the standard Scrum backlog approach.