Although not yet to the big project that I have coming up, I’ve had the opportunity to try out formal user stories for the first time for a project. Before this, I was using a method that mimicked Joel Spolsky’s painless functional specs. Most of this process I will maintain, except I’ve moved to the “As a (role) I want (something) so that (benefit).” user story format proposed by Mike Cohn in User Stories Applied.
I find that using this format really does help me 1) write from the user perspective, which is hard for a developer sometimes, 2) really think about the motivation for the feature and 3) keep the description concise. The details will need to be further fleshed out and explained in greater detail as the feature gets implemented, but this has been a quick route to a common ground understanding of what will be delivered.
The one problem I’ve had via this collaboration is that the first time around I assumed the reason for benefit and I was wrong. This might seem minor, but the truth is that the benefit to the user is the reason for their passion for that feature. I apologized and corrected this and have made a mental note. This was an assumption that I shouldn’t have made.