====== How Do We Write User Stories When We Cannot Get All Development and Testing Done in One Sprint? ======

<WRAP todo>Work in progress</WRAP>

What we really want to avoid is water falling Sprints, where we dev in one sprint, and then test in the next. The reason user stories don’t work well when you have this happen is that the purpose of a user story is to help deliver value (user’s perspective). If you split a story based on tasks then you are not delivering business value. The result is that you are increasing risk (as you don’t have good understanding of the true status of development) and are typically slowing things down (large batches of work trying to go through the system instead of small batches) and lower quality.

When teams tell me this my first question is “have we really exhausted all avenues for doing dev / test in sprint to product running tested features”. Development often has this idea that we have to complete something for release and that takes  Sprint to develop. Ask “what can I get in one week if we assume that not all the fields (for example) that will eventually be required would appear on the page." 

This goes to idea that agile is about “(technical) implementation is a separate event (business decision) to release” or “deliver on a cadence; release on demand". 

Or ask “what will you implement first?” and use this discussion to see if a “value oriented” breakdown appears. Mostly this kind of thing is caused by a develop holding on too long to the code, only wanting to hand it over to cert when everything is done. 

In particular we need to establish a team process whereby a developer, for example, checks in code at the end of every day so that the tester can work on something. This will make the overall process less of a handover, and allow the team to work together better. 

And finally, what is the approach to test automation? The dev sprint / test sprint thinking usually results when there is manual testing everywhere, rather than an approach to automation. Above two questions will help drive behavior, but if you have no test automation then you are going to be doing suboptimal things for a long time.

These are just ideas, based on things I’ve seen before. Let me say that there are hundreds of other things that could be happening, so I really don’t know if this helps at all:-) Bottom line is that the aim is to get user stories being delivered every couple of days during a sprint, with the first one being completed say 3 days into a sprint. If you don’t have this your user stories aren’t small enough. If you are not there it is a symptom of a problem in how you execute.

{{tag>Consultant Tools UserStory Stories FAQ ToDo FirstSprint}}