Extracted from LimitsOfUserStories
UserStories are great.
When using them I find that I have been saying to myself "You have been using this style to describe the functionaliy of a system for years, what makes this any different?" I can answer by saying "Before it was on scrap paper and emails to others, this is more directed". A measured step to add a little bit of formalism without sacrificing the usability of the process goes a long way.
The trouble I am in now is that I am trying to use the same style to describe EVERYTHING I am doing. This is the intense desire to have 'one mechanism'. But what I end up with is a bunch of stories that describe everything lumped into the one category.
I have had some success in placing stories into categories. Uncomplicated enough to get pass the quagmire of 'everything'.
Why do I have the desire to write a UnitTest for this?
Here are my categories:
1. Business/Feature "Display the account history for the client" 2. Techincal/Architecture "The current (whatever ex:AccountService?) needs data from the old (whatever ex:Mainframe) 3. Technical/Science "The data is persisted in some proprietary data structure, the service needs it in XML" 4. Technical/Engineering "The system must have a minimum response time of 3 seconds" 5. Technical/Construction "The system should be written in Python" 6. Business/Admin "This joker needs to pay me for (whatever)"
Categories could run along the lines of traditional requirements engineering:
Functional Requirement == "When cancel is clicked the action should be stopped!"
Non-Functional Requirement == "It would be great if it was written in Python and utilized our RDBMS licence"
Process Constraint == "Task A must be completed within 30 seconds"
Just some thoughts, Richard Quinn