What to do and not do when writing a user story

When writing your story don’t include the “How” it should be done.  That is up to the dev team to figure out the best way to do that and then create tasks/sub tasks to complete those things.  Dipping your toe in the “How” waters can lead to constraining a story to follow what you have written.  You also run the risk of getting too involved with the details of how the story and value is to be delivered and that can lead you to spending time on things that don’t need your attention, which then detracts from continuing to gather requirements and prioritize which valuable things need to be done first.

When writing acceptance criteria, it is important to write them so that you tell the developer and QA resources what you want them to test against.  All acceptance criteria should be testable.  A bad example would be, “X technology passes a flag to X other technology so that a customer doesn’t have tax withheld from their order”.  Instead a better example would be, “Demonstrate that a customer can click a button to then have taxes withheld from their order.”  The first example is too specific and limiting.  The second lets the dev team decide how to make something happen but is easy to demonstrate that it works or not, i.e. if it was done right this would be the result.