Scott Bellware has a post about user stories in which he discusses a very obvious, but not obviously manageable, issue.
<digression>Since being ‘kicked to the curb’ so to speak from the MVP C# program, it’s easy to dismiss a lot of what Scott says as sour grapes. Given our past lack of sympatico, so to speak, it would be easy to for me to dismiss a lot of what he says as someone grasping onto Ruby as a reaction to particular events. But, I think that would be a mistake.</digression>
When using a tool/language/whatever approach like I use with SpecFlow, especially in situations where the developer is also the business analyst, it is very easy to get tied to the particular code implementation that something like SpecFlow encourages.
User stories, as well as the business requirements that drive them, are ‘organic’ in nature, in the sense that they are driven by the immediate understanding of the people involved in determining them. In other words (more or less), they can and should change on a real-time basis. It’s well and good to create BRD documents as a starting point, but what tends to happen is that those requirements become some unalterable things that don’t match up with the fact that as you develop software, they need to change.
Glossing over the details wildly, when using SpecFlow, the user stories are embedded in code. But since you want every0ne to be able to adjust user stories, there’s a gap there. When a business user wants to change a user story based on new requirements, or whatever, there’s a gap there. How to match up the actual intent of a user story with what needs to be in code?
I don’t know what the answer here is. With the projects that I have control over, it’s (more or less) easy to make my code-embedded specifications match my user stories. But, how else to handle them otherwise?