What is the best way to write user stories that are easy to convert into programming tasks?

There's no substitute for direct programmer experience on real user tasks. Getting a code monkey out of the monkey house for one day to help a user, even with simple work, will pay off for months. If you're writing lab management software and there's a programmer on the team who doesn't have a lab coat and safety glasses, you're in trouble. If your team contains programmers who are completely alienated from the users's world, you will die of carpal tunnel syndrome from writing user stories and specs before you produce good software for those users.  This is one important reason why vertical-market software is almost always much worse than general-purpose software and software designed for developers.

I am not sure if there are any magic recipes to make the developrs job simple... but if you add the following ingredients to the user story, you might just help your developer save you a lot of headache. Lets take an example that you have to write a user story for publishing a photo. Lets see how we write a user story from which a dev can derive tasks effectively if not easily. 1. Add a flow of the feature as a part of the use case. In this case it should tell you the overall flow. Like a flow chart that explains from login to publish of photo. 2. Have your user story contain Basic Acceptance test cases e.g. User is allowed to select 1 or more local pictures from the local disk or user is allowed to select one or more files less than X size 3. Add some basic mockups or wire frames 4. Add pre and post requirements e.g setup data etc 5. Add potential validations that should occur pre and post actions So lets see how this user story turns out... I am keeping it to minimal for now: Basic Path 1. Once logged in user sees a button to publish a image 2. User can click on the button and select one or more images 3. Once selected the images will be displayed in a thumbnail view and each thumbnail will hold a text box for the user to add description and tags for the image 4. Image cant be more than X mb 5. only jpeg, png , gif images are allowed to be uploaded 6. User should be able to select images to be published from the local disk even if no JVM, Activex support is available for the borwser or OS. 7. Once clicked on publish user should get a success modal box that disappears in 30 seconds 8. User should then get an alert box to allow sending invitation to his friends attaching the image url.   Alternative path 1. should work on FF, IE , Chrome , XX 2. Once uploaded this should appear in the action history of users latest actions 3. Users friends should be able to see the image publish action for the said user. 4. published image can be downloaded by user himself and or anyone who can see his profile. 5. User has a choice to activate the image to private where only he or his selected friends can see Flow  A diagram explaining the flow Hope this helps.

The element of any form of "requirements" analysis or "design" practice - (user stories mix elements of both) that gives programmers fits - is semantics.  User stories use words to describe a problem that someone wants solved.  The best practice I have found for helping programmers or whatever technical team members are called is a semantic analysis. Here are the steps of the semantic analysis: 1) decompose each user story into nouns and verbs (ignore adjectives and adverbs for the moment) 2) nouns are either subjects (actors) or objects (metaphors) - list our the actors and metaphors and make sure we have a definition for each that we like.  (I say we like, because we have to use these to ensure consistency across stories). 3) verbs are what the story accomplishes.  The actor, can accomplish the verb relative to the metaphor(s).  If the verb is an action verb (change the state of metaphors) that it important for the programmers to understand.  If the verb is a vision verb (see some part of the metaphors) that is important.  4) Compare the actors, the verbs and the metaphors to a product domain "dictionary" that allows you to see if you are creating new actors, verbs or metaphors - and you have your basic model layer definitions. 5) negotiate collisions, synonyms and definitions to ensure consistency in the dictionaries. 6) adjust the stories to use "domain" terminology and return to the story author or customer with the adjusted story and the associated definitions from the domain dictionary to ensure no translation errors. This is a basic practice to ensure consistency and to expose key concepts that inform the domain model.  If you have programmers who can't understand stories with this form of decomposition, have them spend some time studying Eric Evans book "Domain Driven Design".  That should give them the clue. ------- For extra credit, take the adjectives and adverbs from the story - and turn them into acceptance criteria by defining what they mean: 1) how fast is fast enough? 2) how easy is easy enough? 3) how resilient is resilient enough? If the adjectives and adverbs cannot be adequately qualified or quantified - remove them from the story - as undefined.  Your user community will write new stories based on what you deliver for improvements if your initial version is not good enough.

Is actually quite simple. Just provide the necessary context by stating who, what and why. For example, "As a user, I want to transfer money to another account so that I can withdraw money." With this information the developer usually has sufficient context to either get to work or ask meaningful questions or point out edge cases you might not be aware of.  Sometimes it's helpful to state "when" As the story approaches the top of the backlog, more details will be flushed out and consensus on "how" will be decided and story points estimated or re-evaluated  Then you are ready to define starting conditions and acceptance criteria.  Failing unit test can be created and THEN the feature can be started. Wash, rinse, repeat... Deploy.

The best advice I ever received was to focus on the what, not the how. What do you need your application to do in the simplest terms possible, what is the business value. If you have to tell the developers how to turn your business goals into tasks, you may a) have the wrong team in place; b) need a more senior developer to assist.

It's deliberately called a "User Story". So it's supposed to express a bit functionality - facing the user in most cases - that brings value to the end user. The actual implementation work of "the team"  should be expressed in technical sub-tasks. You specify those during the Sprint kick-off if you work in Scrum. Then is the time to make sure the team understands the Product Owner's intent and the technical tasks to fulfill it. It's the Scrum Master's role to faciliate such discussion and story definition. The team shouldn't commit to deliver a story they don't fully understand.

I try video recording. I have found use-cases to be a very dark art in IT, I have recently worked through as an architect on a project that started with about 12 use cases, all with basic flow and alternative flow.  I even converted these to UML.  UML graphs helped, but actually is deciding the layout of pages the entire idea was pretty weak, and the coders end up constantly asking questions the covered the entire design to the business rep.  In frustration I have started a different approach myself.  People don't like to read and generally even the best use-cases will be left because coders don't have time to read them.  If you have a good architect he/she might be able to convert the use-case to wire frames and logic code that developers will be able to follow, in UML, but that almost never really happens. I have been testing using video to capture the use-cases.  One person holds the iphone and the other person just acts out how using the tool would work.  This not only captures sequences of steps, but in an age of multi-channel platforms it enables a coder to get a richer sense of the context the code will work.  Video also has the advantage, unlike UML, of it makes sense to everyone.  Really only a tiny percentage of developers can understand UML. There is something about showing a person walking on the street clicking on a smart phone that brings how key factors about how the solution has to function that no UML document can capture. The core problem with use-cases is that they are 1-D, even when they are on 2D UML they capture a sequence.  Web pages and wire fames need to be 2D, so there is a black art in converting the sequence of actions and information flows to a layout.  So series of videos showing how the tool will be used, updated as the code is developed, can give a richer sense of how the code is suppose to function.

Start with the user-experience. Think backwards and forwards through the desired data or outcome you need. Design it. Code the design. Make sure the UI code is reusable. Write stories that describe the ideal user-experience. Let your engineers complete their magic. Make sure that magic gets unit and automatic (acceptance) testing. Ship. Rinse. Repeat. Start with the user-experience. Always.

Use cases are often used to generate requirements which are then turned into a functional specification.  In other words, the flow may look something like: use cases -> requirements -> functional specification -> implementation Of course, in a web startup, these steps are often contracted. You should talk to the programmer on your team.  If you give the person a list of requirements generated from the use cases, he should be able to generate a functional specification, break it down into tasks, and then implement it.