When discovering stories for the first sprint, how do you know when to stop writing and move forward?

I've asked a few people I know, and basically the response I've gotten is, it depends on the context the project exists in and how timeboxed the overall project is as well.

Is there any standard way for knowing when to stop writing user stories, and if so, what is the basis for this, and how does it apply to future sprints?

  • 2
    As soon as you run out of round A financing. – Job Jan 26 '12 at 19:52

You need to estimate each story once you have fleshed it out - this assumes that you are getting your stories in order of priority and that they are elaborated enough for development.

When you have estimated enough for an iteration, start coding.

  • +1 @Oded: Yes, that's one approach I've run across though do you start by finding epics first, then themes, and finally moving on the executable stories after the "important" epics/themes are "done"... or do you attempt to find as many executable stories as fast as possible, and move forward? – blunders Jan 26 '12 at 20:14
  • 1
    Yeah, your product owner (or whomever) should be feeding you these stories in priority order. You might want to go a little past what you think you can do in a sprint, so you have some extra stuff... just in case. It's not wasted work either way, as you're going to have to do the work regardless, it's just a question of when it gets done. – Brandon Jan 26 '12 at 20:48
  • 1
    @blunders - You start with the highest priority. Elaborate till it is well enough understood to estimate and implement. Rinse and repeat until you have estimated enough for an iteration - at that point start the iteration and coding. – Oded Jan 26 '12 at 21:08

When you have a complete product backlog, and good complete user stories of all cases. Then divide them into iterations, and start programming.

  • 2
    +1 Thanks for sharing, and yes, that's one approach I've heard in the context of a project that's timeboxed; think fixed-bid consulting project. That said, in my opinion agile is about learning, and if you attempt to know everything before starting, that's really not an agile approach. – blunders Jan 26 '12 at 20:24

The two activities are not antagonistic.

Story writing is about defining the desired needs under the constraint of providing business value.

Starting to code happens in the middle of a sprint. To start a sprint, the only prerequisite is a defined sprint backlog - priorized by the PO (the story writer) and selected by the team.

You should stop writing stories (=stop the project), when the marginal benefit af implementing the story versus the cost of implementation and actualized operating cost of the defined function is négative.

You should start to code in the context of a sprint, when the story is understood (analysis) and the testing and implementation are defined (design) - the classical software development approach.


when the stories become granular enough to turn into programmable logic.. and when programmers can award a certain amount of story points that fit within the sprints timeline..

a story that is estimated at 50 hours/story points would be tough (IMO) to take on over a week long sprint.. breaking the story down further would allow for others to take on various parts of the task, but if the code cant be developed in parallel, then that's probably as short as you can go.


Is there any standard way for knowing when to stop writing user stories, and if so, what is the basis for this, and how does it apply to future sprints?

I don't personally know of a standard method per se. It really comes down to a combination of your methodology, and your customer's expectations.

I have found that it is better to start coding as soon as you have "enough" stories from your customer to make a start. As others have said, this could be for a single iteration, however it could be for more. Your measure of enough should be guided by how often you intend to release working code to your customer, and rather than have your customer give you and endless list of stories (many of which will probably never get done, or might change, or might not make your major release deadline), it's better to ask your customer for the first 3-5 most important and highest priority features. When those are done and released to your customer, you collect the next most important 3-5 features and so on. Ask for more or less depending on how long your iterations are likely to be.

Your customer or contract or deadline perhaps may guide you as to when to actually stop asking for stories, yet in the meantime, you have been asking for stories and stopping as often as you have had iterations. When by agreement you and the customer feel the product is complete enough, you can then decide what to do with any left over stories that the customer may have not given you yet.

The main advantage of this approach is that you end up delivering the greatest value to the customer up front, and as the project grows and time passes, the amount of value you are delivering to the customer decreases to the point whee the customer can make a decision about the "last 20% of features" that they might have wished for which might never actually be used. It also cuts down on time wasted on trivial and low priority items, putting the responsibility (and stress) of prioritizing and scheduling iterations back on the customer, and all based solely on the customer's needs. That doesn't mean however you shouldn't provide guidance to the customer in order to avoid difficult scheduling bottlenecks that may become apparent as you talk requirements with the customer.

Have a read of the Poppendeicks' Lean Software Development if you'd like a more detailed description of this approach in a wider context.


you never stop writing stories.. It is just that when you have enough stories for sprint 1, you will do sprint planning and your team will start working as per the sprint backlog..

Product owner will continue grooming the product backlog i.e. writing more user stories, breaking large stories i.e. epics, into smaller one, elaborating more on stories acceptance criteria, prioritzing...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.