User Story is suitable for describing what user needs but not what user does and how system reacts to user actions within different contexts. It basically gives product team a way to quantify their output and let their boss know that they are doing their job. As a developer, you can’t write code from user stories because you have no clue on what what is the sequence of user actions and system reactions, what are the validations, what APIs to call and so on. As a QA, you can’t test the software from user stories because it does not capture the context, the sequence of events, all possible system reactions. User stories add little value to dev lifecycle. It only helps product team understand how much work they have to do eventually and it helps finance team get a view on how much money people are talking about. But to UI designers, solution designers, developers, they are nothing but blobs of highly imprecise statements that leave room for hundreds of questions to be answered. The absence of “Context” and “Cause and Effect”, and the imprecise way of saying “As a…I want… so that…” leaves room for so many misinterpretations that there’s no way development team can produce software from just user stories without spending significant time all over again analysing the user stories. Software, and the universe eventually, is all about Cause and Effect. The Cause and Effect is not described in a user story.
Unlike user stories, the “Behavior” suggested by Behavior Driven Development (BDD) is a much better approach because the format of a behavior (Givencontext, When event, Then outcome), when used correctly, lets you think in terms of sequence of events, where the context, event and outcome are captured for each and every action user or system does, and thus works as a definite spec for designing the UI and architecture. It follows the Cause and Effect model, thus can explain how the world (or your software) works. It can be so precise that sometimes a behavior work as guideline for a developer to write a single function! Not just the develoeprs, even the QA team can clearly capture what action they need to perform and how the system should respond. However, to get the real fruit out of behaviors, you need to to write them properly, following the right format. So, let me give you some examples on how you can write good behaviors for UI, business layer, services and even functions and thus eliminate repeated requirement analysis that usually happens throughout the user-story driven development lifecycle.
Read more about how user stories suck and if behavior is used throughout the development lifecycle, it can greatly reduce repeated requirement analysis effort and can make the communication between product, design, development and QA team much more effective:
http://www.codeproject.com/KB/architecture/userstorysucks.aspx
If you like it, vote for it!
I think there is a key piece of user stories that was left out of the discussion in this post. As per agilists, a user story is a “placeholder to have a conversation”. The fact that we are attaching a who, what and why is not the end-all be-all of the requirement or the behavior.
I think there are a couple of issues with your statement ” The absence of “Context” and “Cause and Effect”, and the imprecise way of saying “As a…I want… so that…” leaves room for so many misinterpretations that there’s no way development team can produce software from just user stories without spending significant time all over again analysing the user stories.” If someone is spending a significant amount of time to write a single user story during any point in the release planning or development process, they’ve missed the point. Again, a user story is a placeholder for a conversation and does not in and of itself constitute anything resembling a complete requirement. That would indeed leave open a considerable amount of room for misinterpretation during the development and QA phases for the feature in question. The more significant amount of time in the process should be spent after the user story has been written. The next point missed is that acceptance criteria (read: expected behaviors) for the story must be defined as part of the process. These should focus on delivering the value to the user as stated in the user story. The story should not be worked on by the development team until after the acceptance criteria has been defined and agreed upon by the product owner, other stakeholders, QA and the development team.That is where the more significant amount of analysis time is spent.
If indeed all we have is the user story as the complete requirement, then I guess I would have to agree that they would be worthless. Behavior gets defined in the acceptance criteria and is part of the process rather than a replacement for a user story. User stories can be integral to the parts of the process that they are critical to in terms of determining a forecasted scope and prioritization of a release prior to spending a chunk of time in deep analysis. I’d rather spend 2 minutes on a story that the product owner can throw out rather than hours on defining the behavior represented by the story.
I rather enjoyed this post as it challenges me to make sure I understand what it is we do, and why we do it. Thanks for posting it.
regards,
Jim Erwin
Completely agreed with Jim.
Code is behavior; behavior is code!
User stories describe code (behavior) that does not exist yet!
Your call for behavior is a call for a complete, waterfall-like spec/architecture.
Of course user stories need to capture all side effects and implicit assumptions!
Code is not behavior. Thus Behavior is not code. So, your understanding is incorrect.
Behavior is specification.
User story is a specfication as well.
The only difference is in preciseness.
agree with jim.
stop posting this rubbish
@Jim, thanks for the insightful comment. I do agree with your view that user story is a place holder for conversion. Now Behavior is certainly not the end of the story. Behavior helps design team produce better design, it helps developer write and check code against the behavior, it helps QA perform the actions in sequence and verify the outcomes. It’s just a better way to refer back to the requirement and precisely match the outcome where user story is dubious when you want to go back and match your work against it.
Design, code, test – all of these are done after producing User Stories. So, Behavior is certainly not a dramatically different approach, like what sibidiba said, the waterfall model. All it says is, let’s be more precise in defining the stories and let’s follow the cause and effect model. It certainly does not say, go and write down each and every requirement in 100% precise form before writing code. You can certainly define 10 behavior, start a sprint, prototype, design, code, test and deliver and then write another 10 behaivor and start another sprint. All it says is, let’s define those 10 requirements in behavior format, instead of user story format, so that it helps designers produce precise design and then match their design against the context, action and outcome; it helps developers write better code and then match the output of the code against the cause and effect; and it helps QA perform the tests in the exact sequence as defined in behaviors and match the output as defined in the outcome of the behaviors.
Once easy metaphor can be that if you are asked to write a story, you can go ahead and write it in whatever chronological order you want, or you can follow a chronological format where you first tell the background, then the actions, and then the end results.
I think readers got the wrong impression that behavior is the end of the world. Once you have defined the behaviors, go write code, don’t do anything in between. That’s certainly not what you should be doing. Everything you do after you define the user stories, whether it’s some intelligent conversation, or producing design documents, or drawing prototypes – you do all of these after defining the behavior. The advantage of defining requirements as behaviors is that it allows you to express the requirements in a more precise way, following a cause-effect pattern. This pattern is very helpful since software follows the cause-effect pattern. It does not follow the want-so that pattern, unless we get a AI Programming Language that can read users intention and respond.
Hope this clears the air.