Questions And Answers About User Stories

Post UserStory questions here:

Question: How do error conditions get handled with this scheme? I'm talking about things such as communications links being lost etc, not user error. Are they just things that need an EngineeringTask being created when the UserStory is broken down?

In your example I'd suggest a story something like "When a communication link is lost the user isn't notified, but instead the system fails over and logs an error and ...". Or note that "24/7 reliability is vital to this communication" as a Quality on some UserStory about communication. If neither of these were present, but an EngineeringTask needed some response to a communications failure, I expect we'd just DoTheSimplestThingThatCouldPossiblyWork. --PeterMerel

How effective is the UserStory in launching new technology? I understand how it would be effective with incremental change to a product, but not with an entirely new product. It might have gotten us better horses, but I don't see how it would have gotten us from horses to cars? --CayteLindner

Personally, I can't see how user stories are sensitive to new or old technology - or, at least more sensitive than anything else you can use. The user has never seen a web site. You talk to him/her, and kind of mimic what a web site does, or take him/her to Amazon. Then he/she tells you a story of how they want to work, and you have a story.The user is rarely in the business of inventing new technology, usually the technologist is. The user story is a marker - a sign that the user wants value here and like this - it is placeholder for a conversation about how the system should exactly do that. If there is new technology involved, the user story won't resolve it, prototypes, demos and feedback will resolve it. -- AlistairCockburn

Why IndexCards?

'Cuz they're not formal looking, they're more durable than napkins, and Kent likes them (read his opening comments, above).

question: When estimating user stories, do you estimate them in isolation? How do you handle apparent dependencies among the stories?

In trying to do user stories, we had some difficulty estimating them. We knew that certain stories were closely related to other stories -- it seemed obvious to us that they would share some engineering tasks. We thought that story A might take 4 days, and story B might take 4 days, but it looked like about 2 days out of story A were the same as about 2 days out of story B, so that once story A was done, story B would take only another 2 days, not the 4 days if it were done without story A.

answer: We estimate in isolation even if cards relate closely. In some situations, stories that are related, but do not depend on each other, do not have to happen in any particular order or even the same iteration. Therefore, it is important to give them equal value. --ShellyGraves

question: How do you convert UserStories into a Software System Specification? My development team is contracted to the government to develop software and part of their instructions is that there will be a Spec and about nine other documents.

I'm desperately holding onto the hope that you are joking with this question. A UserStory is not a spec, it is a promise for a future conversation. The spec lives in that future conversation, i.e., verbal.

You have hit a limitation of UserStories and ExtremeProgramming. XP is good for generating software but not with being DocumentationCompliant. When you are dealing with the government, the ForkLoads of documentation is part of the product.

In the early 1980s, the US DoD was using a documentation method called story-boarding. This required a document to be formatted with a picture on the left or even numbered page and 1 page of text on the right page. This sounds awfully close to a user story to me. You might try digging around to find a reference to story-boarding somewhere. -- WayneMack

question: A UserStory is comprised of 1 to n EngineeringTask(s). A developer who signs up for an EngineeringTask estimates the IdealProgrammingTime required to complete the task. From what I have seen here, it appears as if the UserStory will be estimated before any of the EngineeringTask(s). Am I correct in that assumption? If so, how close do the estimates on a UserStory come to the combined estimates for all EngineeringTask(s) required to satisfy the story? Are we just ballparking the estimate on the story, or are we thinking about the tasks at the time the story is estimated?

Or, are the EngineeringTask(s) estimated and then summed to arrive at the estimate for the UserStory? I would think it to be too early in the process to come up with task estimates for each story. -- KenReigle

Answer: According to ExtremeProgrammingExplained, stories are estimated as 1, 2, or 3 weeks in a meeting with the whole team (the team owns the estimate). Planning game occurs, and these estimates are used to guess at what would fit in an iteration. After that, engineering tasks are devised, people sign up for them, people estimate tasks (1, 2, or 3 days), and if the tasks add up to something wildly different from the story estimates, somebody goes back to the client.