Just-in-Time User Stories (in the Product Backlog)

Appointment Time

In our summary post of Scrum, we refer to the Product Backlog as “a list of functional and non-functional requirements sorted by importance“. This post aims to improve and add to this definition. We have decided to go with user stories in the Product Backlog.

A user story is a short description of a functionality which is of value to the user or the customer (Product Owner).


  1. Start out with a product backlog with coarse descriptions. Think of stories in it as short topics for discussion with the customer. (I.e “A user can launch a rocket with one click of the mouse”).
  2. As the story advances in priority, it might be broken into even smaller stories – thus in effect increasing granularity.
  3. As a story is up for implementation, it is discussed in detail with the customer. The customer is helped with writing acceptance tests to clarify all details and to obtain a definition of “done” to the story.
  4. Keep the customer available for further details during the sprint planning and the sprint.

This is how to best work with user-stories, adding details just as they are needed — relying heavily on face-to-face discussions. Some more details follow.

Coarse User Stories as Discussion Topics

Start out by writing super short user stories in the Product Backlog. They might even be too big for any realistic release planning purposes at this stage, but provides a very good overview of the system. Let us imagine that we are planning the project “RMS”, or “Rocket Management System”. Let us start out planning the project together with the customer with coarsely defined stories like this one

– A user can launch a rocket with one click

Seeing a coarsely defined story like this, you probably know how tempting it is to start talking about how this could be achieved through hooking up the button with an XML-push to the rocket-launching system and stuff like that. Don’t think of these things right now. Let us put in a few more stories.

– A user can launch a rocket with one click

– A user can abort a rocket launch.

– An administrator can issue a ‘rocket list of the day’.

– An administrator can plan a series of automated strategic missile-attacks up front for the weekend when he is out fishing.

(And for good measure, being a rocket system and all, let’s add the following: )

– A user must log in to the system.

– A user must re-verify when launching a rocket.

Break a story into smaller stories

It is normal for a story that has reached high priority in the product backlog to be broken into more stories as focus on its details increase. By smaller we refer to how big their estimates will be. This in effect adds to the level of detail. The story “A user can launch a rocket with one click” might be broken into the following stories as we start thinking more detailed on it.

– A user can select a rocket impact destination.

– A user can launch a rocket with one click

– A user can change rocket impact destination mid-flight.

– A user can detonate a rocket mid-flight.

– A user can set the rocket on pause.

This means that the stories that are closer to implementation will normally be smaller than the ones that are further into the future. This is just as it should be. Using this technique we have a coarsely defined Product Backlog, which serves as a good a specification as the most beautifully crafted requirements document that you can imagine. Why is this so?


By deferring details on each story until the last responsible moment, keeping them on the level of topics for discussion, we are forcing developers and customers together for face-to-face discussions. Certainly no developer would be so foolish as to start developing a “Rocket Management System” with the current level of detail we have in our Product Backlog.

Bringing them together we are all set up for transferring tacit knowledge about requirements and system expectations in moderate sized portions; we will only discuss the stories which are due for implementation. Tacit knowledge, as we know, does not transfer through requirements documents.

The importance of face-to-face discussions cannot be stressed enough.It is all too tempting to think that a fat requirements document is the safe and professional path, but a good old sit-down with face-to-face discussions are transferring information that a requirements document could never dream of conveying.

Developers use details from this session to create any documentation they need for remembering the details. Details are very welcome at this stage, as we are just about to make use of them.

Acceptance tests (customer tests)

It is important that details in the requirements are testable. This way we know when the implementation of a story is done. At this stage we write acceptance tests together with the customer. The top priority story  “A user can launch a rocket with one click”, needs the following tests, according to the customer:

– A user can launch a rocket with one click

  1. Test that not one in 10 new inexperienced users mistakenly launch the wrong rocket or launch the right rocket at the wrong destination.
  2. Test that the rocket is fired within 10 seconds of clicking the button.
  3. Test that even after clicking “launch” but before the rocket has launched, the user can hook off other options (such as “Land softly” or “Go twice as fast as usual”).
  4. Test that on nuclear scale rockets, a confirm dialogue must appear. “Really destroy all humans?”.

Writing these acceptance tests together with the customer allows developer to ask questions that might strengthen tests, and remove ambiguity in test-formulations.

Root out assumptions

Having discussed the story details with the customer, the development team goes off on sprint planning to lay out how to proceed with this information. Using the story text, the added details and acceptance tests, the team can define how to get to done. The customer should be available to answer questions that will arise during development, thus rooting out the need for the developer team to make any unnecessary assumptions during the implementation.

Summary, once more, even shorter

  1. Start with coarse stories.
  2. Break into smaller stories as we get closer to implementing them.
  3. Discuss all thinkable details with customer upon committing to implementing a story. Add acceptance tests.
  4. Focus on the communication! Keep up the talk with the customer during the implementation.


  1. Recommended reading : User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series) by Mike Cohn (Paperback – Mar 11, 2004)
  2. 1h:14m long talk held at Agile2008 by Mike Cohn about Prioritizing the Product Backlog, a talk in which he very much enters the subject of user stories. He introduces and elaborates on how user stories can be packeted into “themes” and how future stories start out as big “epics” as he calls them.