This page is TooBigToEdit. I set up LimitsOfUserStories to try to coalesce and sharpen the discussion that is now scattered over UserStory, UserAntiStory, TheExtremeProgrammingWayToHandleUserAntiStories, ThereAreNoUserAntiStories. I hope to focus on the one question, "'''What are the limits of UserStories?'''" as practiced by the XP community (distinct from any limits of UseCases). Maybe UserStories have unlimited requirements function in XP, maybe not. -- Alistair ---- KentBeck writes, "I'm curious about Alistair's contention that there are requirements you don't write stories for. Someone made the comment that non-functional requirements should not be represented as use cases. I haven't seen a non-functional requirement that couldn't turn into a story. I would love for one mechanism to suffice, and I haven't seen an example where stories aren't sufficient. I want to reconcile these views." ---- AlistairCockburn tries, 1 "The customer's last name will be stored as 32 characters max." (generic data requirement) 2 "Response time on user requests will be less than 3 seconds." (generic performance requirement) 3 "System uptime will be at least 23.5 hours per day." (generic availability requirement) 4 "The system will be implemented in Java." (generic programming standard requirement) 5 "The process used in developing the system will be ISO9001 certified." (generic process requirement). The point of the above list is to try to transfer the limits of UseCases to UserStories. Bear in mind that XP operates in an oral culture. Many things that would get written down elsewhere get ''spoken'' in XP. With respect to Kent's desire for ''just one mechanism'', I can't see it. At the same time, I bear in mind two things: * People who can get away with One mechanism instead of Two, have simpler lives. * "System Requirements" is a shared understanding between people, meaning that if the people write stories on cards or speak together, and from those, understand all the above requirements, then their mechanism suffices. My own version to non-functional requirements often has been, "Write it down somewhere, and make to review it at the appropriate moment." Official requirements types shudder on hearing/seeing this sentence, because there are so many projects where this violates a process requirement or cultural convention. ---- Alistair, please say for any/each of your 5 above what part of the XP story management process you think won't work for them. Meanwhile I'll comment on UserStorySystemInJava. Thanks. UserStorySystemInJava led me to WriteItOnaCard. My discovery is that when I've been saying recently to use UserStory for things like UserAntiStory, I've really meant ''For XP-sized projects, Handle UserAntiStory by a suitable application of WriteItOnaCard until it doesn't work any more.''. -- RonJeffries Ron, I don't have to say ''why'' I don't think they'll work. I put forth the thought that you can't write those requirements as a UserStory. You or Kent get to say You're Right, or Here's The Story, or, as you so nicely describe, Never Mind Just WriteItOnaCard. -- Alistair ''Of course you don't'' '''have to''' ''Alistair, but since I don't understand yet what you're getting it, I wish you would. I honestly don't see what's wrong with writing'' '''Do it in Java''' ''on a card.'' It's not wrong. It's just not a UserStory. -- Alistair ---- Okay, I've pondering these requirements. It seems that while not all of them are covered by UserStories, they all can be covered by XP. ''1. "The customer's last name will be stored as 32 characters max." (generic data requirement)'' This can be part your first "track customer info" stories. You can implement this requirement when you create the customer class, or any time thereafter. You can create a UnitTest for this, to guarantee that a 33 character last names will always raise the appropriate error condition. I get the impression that in SmallTalk/GemStone it's relatively trivial to munge through all existing objects and check/enforce some condition on each object's state. In other languages/environments, the CostOfChange might be much higher later on, so you should probably be sure to do it in the first iteration. ''2. "Response time on user requests will be less than 3 seconds." (generic performance requirement)'' ''3. "System uptime will be at least 23.5 hours per day." (generic availability requirement)'' I'm not sure if story cards are the best way to handle these, but you can certainly put them on story cards and implement them in your SpikeSolution, along with appropriate AcceptanceTest''''''s. If your SpikeSolution works, you have just made performance and availability problems into test regressions. If your SpikeSolution doesn't meet your performance and availability requirements, then you need to throw it away and start over, since added complexity isn't likely to make your code faster or more reliable. If this is a high-risk, high-reward area, you should be addressing it early anyway. If it isn't, then maybe YouArentGonnaNeedIt.... ''4. "The system will be implemented in Java." (generic programming standard requirement)'' [Discussion under way in UserStorySystemInJava.] ''5 "The process used in developing the system will be ISO9001 certified." (generic process requirement).'' I don't know that much about process certification, but it seems to me that ISO 9001 certification is just another deliverable, just like documentation. Several people have elsewhere asserted that there's nothing incompatible between XP and ISO 9001, so I'm assuming it's primarily a matter of doing the paperwork. If the team has little or no experience with ISO 9001, it's probably a high-risk activity that should be scheduled for an early iteration. Again there's always the possibility that when Business sees how good you are without ISO 9001 that YouArentGonnaNeedIt. What do people think? I'm just an XPNewbie, so I'd appreciate feedback. -- JohnBrewer ''I think you're right on, John. Just do it until something goes wrong. But I'm the boy with the hammer, don't listen to me.'' ---- Gentlemen (you who have replied), May I remind you, the opening text of UserStory says, (and is followed by) * ''In ExtremeProgramming a UserStory is a story about how the system is supposed to work. Each UserStory is written on a card, and represents a chunk of functionality that is coherent in some way to the customer.'' * ''So I [KentBeck] say, "Tell me the stories of what the system will do. Write down the name of the story and a paragraph or two." ... The idea of specifying the behavior of the system from an outside perspective, and using those specifications throughout the life of the system is the same.'' * ''How are users shown that a story is working correctly? '' * ''The story is used by the customer to make informed decisions about the scope of the next release'' * ''They are sorted into three piles by risk. They are sorted into two piles- this release and the future. They are sorted into three week iterations.'' * ''A UserStory is a story, told by the user, specifying how the system is supposed to work, written on a card, and of a complexity permitting estimation of how long it will take to implement. [from RonJeffries]'' I'm sorry, but there is no way I can consider, "implement it in Java", or "use an ISO9001 certified process" a UserStory, using the definitions of UserStory so carefully sorted out for us over the last 2 years. Yes, you can put them on story cards. No, you can't capture their validity using AcceptanceTest''''''s. Yes, just WriteItOnaCard is a valid thing to do. No, under the definition of UserStory that we currently have, I would say the above requirements don't count as UserStories. And perhaps, in XP, you just WriteItOnaCard anyway (and if it works, great, so what?). But that is (to me) different from insisting they are UserStories. Long reply, sorry. -- AlistairCockburn OK, I think I get it. You're thinking of a UserStory as a lightweight use case which can therefore only describe desired system functionality. I'm thinking of a UserStory as "something written on a card that a developer is going to have to do." Both the UserStory page and KentsBook (p. 90) appear to be on your side. So a UserStory is-a WriteItOnaCard with the additional constraint that what is written describes ''what'' the ''system'' needs to do. As opposed to ''how'' the system will do it, or ''what'' the ''development process'' will be. But the whole purpose of UserStories in XP is to generate the TaskCards that actually drive day-to-day development. As a developer, I don't care if the card that generated the TaskCard was strictly a UserStory, as long as I get a set of non-ambiguous TaskCards out of it. -- JohnBrewer BTW, I think you really can have acceptance tests for each of the above requirements, provided you're willing to count an ISO audit as an acceptance test. -- JohnBrewer ---- ''"The customer's last name will be stored as 32 characters max." (generic data requirement)'' I'm confused again, just like I am in UserStorySystemInJava. How is this a ''user'' story? Most users I talk to count in base ten, not base two. This is almost certainly an engineering task. A user story may be something like, "Must store the customer's last name. Every last name must be savable." I contend that if analysis of the problem suggests that all last names are less than 32 characters, only then you can put this text on the task list. [Tangentially, this requirement&analysis is bogus because some last names > 32 characters and some people don't have last names.] -- SunirShah Again, probably a ContrivedExample. But imagine a program that's a front end to a legacy database, and said legacy database only allocated 32 characters to store last names... . -- JohnBrewer I'm still confused. I'm trying to get a feel for what an XP UserStory entails. For your database example, I'd still reformulate the user story to be along the lines of, "The system was interface with the legacy database \\Foobar." Having done this on a daily basis, I can certainly believe that in the RealWorld UserStories get mixed up with EngineeringTask''''''s all the time because your mind leaps directly to the "obvious" solution, but sometimes the obvious solution is the wrong solution. Moreover, if your user is talking to you in powers of two, I think the user is a little too close to the code to be effective. PropellerBeanie requests and TunnelVision are bound to ensue. At least that's what I've found. Consequently, I started to build a UserStoryShield where I reject any solution-oriented request. Unfortunately, I didn't have enough time to complete the experiment. -- SunirShah ---- I don't think that this is limitation on User Stories, but I am curious on UserCardsThatImpactVelocity Example: Your customer desires that your team develop a portion of the project in java. You have just taken the XP Immersion Course, so the voice in your head tells you "I will write this story on a card". It is an interesting card, in that, this card must be dealt before the first java task can occur. After writing the story on a card, you are tasked with creating an estimate for the card. You may do a TechniqueSpike to understand the impact of java, this spike identifies several tasks for the portion of the team that will works in Java. 1) Training for Java (if you have a C++ Team) 2) Configuration Mgmt Setup 3) Coding standards creation One aspect of the TechniqueSpike may be a VelocityImpactEstimate Example for the UserStorySystemInJava story card Time Est. (15 person week training + 1 week standards development + 2 week config mgmt) Velocity Impact Estimate: 3X velocity Hit over Small Talk What is your thoughts on cards that impact team velocity? -- MichaelSchneider ---- They're not really very special: 1. First, be very careful that you know what you are talking about. It's way easy to use "that will slow us down" to avoid something we don't want to do. 1. The ReleasePlan (CommitmentSchedule) process handles the case. You're going to estimate each card anyway. Estimate as honestly as you can. Mention that if the project was done in Forth, these estimates would be lower, and that you'd stand by them. ----- Good Comments. My goal is not to eliminate a technology, but to identify the cost of using a different technology than the team is familiar with. The new technology may have many benefits that would offset the velocity cost, but that seems to be a business decision, rather then a technical one. This seems to call for the creation of a story with this data. The business person can accept the costs to get the benefits, or reject this story, passing up on the benefits. Ex, If we use XML for data transfer in our product : + interoperation with other web systems : + big marketing Hype : + we get a $10 million dollar check from our third party users for lower their integration costs : - initially slower : - XML requires more time to convert from ASII to Double (if we are a numeric app) than our current binary representation. : - training costs for team = 12 days : - technology ramp up = 3x velocity for first three months. I could be missing something here, but the technical role seems to be to identify the costs of a particular implementation, as well as the technical benefits of the implementation technology. If a technology is being driven by the user, shouldn't this user need be captured as a story? What I am struggling with is capturing user stories that impact the velocity of the team. These seem to be driven by a story, but are factored in when creating a commitment schedule. UserStory -- seem to be able to capture business process models, solution technologies (ex use XML), and other user goodies. Velocity (LoadFactor)-- multiplier from IdealProgrammingTime (estimates on each story) to clock time. CommitmentSchedule -- The velocity seems to be identified here. With the velocity and resource availability you can commit to what stories will be in each release/iteration. My question is "If the user specifies a story that impacts the velocity, how is this captured?" Example: The story "You will use 386-75 Machines to do development". It seems that you would want to capture this and identify the velocity impact of this "story". That way the business people could make a business decision if development would continue on the current machines, or new machines be purchased. It seems to be of very high value to have stories that impact the velocity. What are others thoughts on this? Thanks. -- MichaelSchneider ---- I just rummaged around and found a list of "non-functional" requirements that is used by the AtlanticSystemsGuild (or at least, posted on their site :-). I don't think these change the tone of the discussion from above, but it is at least useful to see what those people collect under the term "requirements". A few of these might drop into UserStories, but I think they mostly just extend the suggestions I made above. -- AlistairCockburn 1. What technology requirements are there for this system? 2. What systems will this system interface with, with what requirements? 3. What values will be reflected in the project (simple, soon, fast, or flexible)? 4. What feedback or project visibility do the users and sponsors wish? 5. What can we buy, what must we build, what is our competition to this system? 6. What other requirements are there on the development process (e.g. testing, installation)? 7. What dependencies does the project operate under? 8. What operations, security, documentation requirements are there? 9. What are the usability requirements? 10. What are the maintenance and portability requirements? 11. What is the human backup to system operation? 12. What legal, what political requirements are there? 13. What are the training requirements? ---- I'm perpetually confused about UserStories. There are two types of requirements: digital and analog. Digital (aka hard) requirements are specific, quantized, always finite in extent and are either completed or not. Analog (aka soft) requirements need to be qualified, can be vague, can be infinite in extent and can be somewhat completed (this can be expressed as a percentage of completion, say). It's usually hard to express how close you are to achieving analog requirements, but it's always easy to express how close you are to achieving digital requirements. A digital requirement would be something like, "Response time on user requests will be less than 3 seconds." An analog requirement would be something like, "The system will be secure." UserStories seem to me to be only digital. You can estimate how long it will take to complete them, you put them away when they are done, you can agree to do them now or later. The whole notion of index cards fits in nicely with the quantized nature of user stories. I don't get how you can naturally represent an analog requirement as one UserStory. It seems to me that just like any other analogy mapped onto a digital environment, you have to break up the requirement into a series of steps (quanta). For example, "The system will be secure" is not a user story, but these are: * The user must enter a login ID and a password before she gains access to the database. * Each document will know about its owner. Only its owner will be allowed to edit it. * All queries outside the internal network will be logged with the query, the login ID and the date&time. What am I missing? -- SunirShah ''Please explain how it is possible to implement an "analog" requirement using any methodology, without first converting it to "digital". If converted, of course, it'd work just fine as a UserStory.'' Unless you push the idea of digital to the extreme (e.g. keystrokes), here are two analog requirements that don't map well to digital requirements: 1. Keep the system well-factored, 2. Have easy and fun-to-read documentation. Both require an inner sense that analytical philosophy has yet to quantify and, consequently, digitize. -- ss ---- I don't really think you're confused, Sunir. Just use your common sense and you'll be right. JohnBrewer got it, up above. Reread what he said. Recalling that way up at the top, I suggested we discuss "What are the limits of UserStories as practiced by the XP community, distinct from any limits of UseCases", I'll put my summary of the situation with these two sentences. * A UserStory is about functionality -- non-functional requirements are therefore not UserStories proper. ''RJ suggests: they are HonoraryUserStories.'' * Kent and Ron manage requirements statements of all kinds with the strategy: WriteItOnaCard (as HonoraryUserStories), then read each card and use common sense, and when necessary SitOnTheOtherCards. Note especially the application of common sense (is "UseYourCommonSense" one of the values or practices of XP yet?) ''We'd say "UseYourCommonSense consistently with the ExtremeValues.'' -- AlistairCockburn ---- Next question: Why is it important to make a distinction between UserStories and HonoraryUserStories? As Development, they are all things Business wants me to do, that will eventually generate task cards. Unless I'm missing something, making this distinction seems to violate OnceAndOnlyOnce. -- JohnBrewer ----- Oops. I thought we had it clear -- not everything generates a task card. Suppose Business tells you, "Let's work so we go home with a good feeling on Fridays." That won't generate a task card. Go through that list of non-functional requirements again. When did this infatuation with task cards spring up? I really do begin to feel like there's someone with a brand new hammer around here. -- AlistairCockburn ---- I'm still hung up on negatives. Like * Students must not be able to change their grades. I see that writing it on a card is a start, I can imagine tasking someone to do this, and then I run out of faith. Is their any data on such negatives being handled successfully? -- DickBotting ----- Well, now I'm confused, too (see Sam's examples in UserStory). The examples of UserStories here on wiki don't match Kent's description. Until Kent writes his view of the matter, I think I'll just stay confused. -- AlistairCockburn ----- I think part of the confusion here relates to the fact that many of these types of requirements belong in ServiceLevelAgreement''''''s with the customer or user. These agreements tend to be global in nature and create boundaries and constraints on all project deliverables. One must then engineer the deliverables (UserStory) to fit within the agreed upon constraint. -- JimEatmon ----- My really, really uninformed 2 cents... I'm a little curious why something so fundamental to the XP methodology and which on the surface appears to be quite simple and straight forward ends up so difficult to pin down. There seems to be the same need/desire/confusion for UserStory examples on extremeprogramming@egroups.com. The explanatory gamut runs from "Anything important that can be written on a 4x6 index card" to "a short narrative of a atomic interaction of the user with the system." I'd suggest User Stories for User Stories but that would lead to infinite regress but anyone who's watched Star Trek knows that that always leads to problems (or is that temporal anomalies?) Reading some of the posts, I can see that somethings clearly don't appear to be USER stories. Prima facie, "Students must not be able to change their grades" does not appear to be a user story whereas "A user will gain access to the student grade system based on appropriate security precautions" if vague, does. If a student clobbers a teacher over the head, finds his password written underneath his pencil holder and logs on, clearly, that is not the developers' fault. Additionally, "you must use Java" doesn't feel or smell like a UserStory if the term isn't to enter the realm of the Caterpillar and his Hooka. On the other hand, if you take a UserStory like "Janet schedules a meeting between James and Agnes on the 24th at 1 pm by initiating a request for a meeting which determines if both participants' calendars are free and if a suitably large meeting room is available." It is possible that both are free but Agnes has a 9 to 12 meeting in Paris which makes it physically impossible for her to attend a meeting in San Francisco at 1 pm. Not all temporally possible meetings are physically possible (I knew Star Trek would come into this somehow). But I'm not certain that a desire for no negative outcomes can't be converted into a story of only positive outcomes. The result of user interaction should be a meeting that both persons are physically and temporally capable of attending in a room that will accommodate them both. With regard to the "you must use Java" and "last names must be 32 characters or less," I'm not certain that you don't have an implicit requirements document in hand or are getting one from the Customer. After all, what has gotten you as Developer into your position? Customer choose "build from scratch" over "out of the box", "outsource" over "in-house" (or vice versa) and, then "you" over "the other guy" (Or you may have had a hand in those decisions). I think that the question can be reframed as "can every program/system feature be reduced to a story of user interaction that doesn't completely damage the idea of 'user interaction with the system'?" If the answer is "no" then UserStories are necessary but not sufficient; we write the other stuff on index cards, call them something else and factor them in when we write EngineeringTask''''''s. Another way to look at it is to apply UserStories to other types of products and other types of professionals. What would the UserStories for a car look like? A book? A pair of jeans? What would they look like for a lawyer? An accountant? An architect? Other interesting questions include when should the developer suggest features or user stories (based on Kent's [?] definition that a UserStory is Customer initiated)? For example, Vaporware International doesn't necessarily have any expertise about meeting scheduling software whereas a developer may have experience from similar products. Vaporware International may be full of American board members who don't realize that December 26 is a holiday in the UK and that the French prefer (and some say insist on) reading French. Heck, businesses don't apparently even know how to run businesses if the number of consultants is any indication. I also see the possibility of the user leaving out the system as user as in the case of the meeting scheduling program asking a meeting coordinator to change the location of their meeting of 10 in a room with a 100 person capacity (it was the only one available at the time) when a smaller room has opened up. Giving the customer exactly what they want and only what they want may not be in their best interest; of course, neither is giving them more than they need. Boy that was a lot longer than I intended; I hope I didn't blather too much. -- StephynGWButcher ----- What I really wanted to see was more examples of UserStories. The one example I have above, "Janet schedules a meeting between James and Agnes on the 24th at 1 pm by initiating a request for a meeting which determines if both participants' calendars are free and if a suitably large meeting room is available", seems to solve about 50% or more of the software "problem" to be solved. If a UserStory that is too long is to be just ripped up and made smaller, how would you make the above UserStory smaller or more manageable, given a 3 week iteration? Can anyone add any UserStories for Vaporware International's meeting scheduling program? It might help some of us (okay, me), if we all focused on the same problem and put ourselves in the Customer's shoes -- what do we expect of them -- and at the same time actually came up with examples of UserStories. Just an idea. -- StephynGWButcher I'm not sure the story needs breaking down, because I would estimate it as a week or two as it stands. However, YMMV, so let's assume with you that it does need breaking down. In the story there are multiple bits of functionality, with different value in the app. Clearly the value of scheduling the people has different business value from scheduling the room. They can always meet in the parking lot, or in the can if they are of similar gender. So what would happen if you started with fixed meeting sizes, or without rooms, or didn't allow people to schedule meetings they weren't going to, or such. Please try to break it down, see what you get? If you're entirely stuck, I'll help. -- RonJeffries ---- StephynGWButcher replies...why specifically does specificity make it more of a Use Case than a UserStory? UserStories are often described as having backup of some kind. What is the difference between them? ''I'm honestly not sure why it sounded more like a UseCase. Maybe it was so much explicit reference to specific users. I'm probably off base and am removing the comment. -- rj'' It's partly my fault because I wasn't clear myself on what question I was asking. I implicitly wanted to know two things: (1) was this a User Story and (2) if the implementation of this User Story fell outside of the iteration period, how do you write a coherent shortened story for something that seems so pivotal? I mean, except for bells, whistles and exceptions, the story above *is* the meeting scheduling program. I was trying to get an idea of how you shorten a story to make it still a story, an atomic bit of functionality or business value or what-have-you. I think you answered that question well. Using Alistair's icons, I thought I had a wave when I had a kite. I would guess that the answer to (2) depends on what the other UserStories are...no UserStory is an island. If the schedules UserStories are in place (implemented), then the implementation of the above example is trivial; if they aren't, maybe they should be. I'm still troubled by (1) however. If at first glance, it didn't look like a UserStory, why not? What does a UserStory look like? I think I've made this more clear on my post to extremeprogramming at egroups.com, message 4935. Unfortunately, I have your rejection of my example in there, but that will all get sorted out, I hope; and if not, I'll do it myself. Otherwise, I'd like to continue this discussion there and maybe post a synopsis here. I'm still looking for extended substantive example of User Stories and XP in general. The Coffee Maker Example on www.extremeprogramming.org looks moribund. Perhaps everyone is off writing books and I'll just have to wait until they come out ;) Maybe we can collectively take up the meeting scheduling system (no, I don't have a meeting scheduling project, it's from a book. I'd like to compare methodologies). -- StephynGWButcher ---- ''UserStory ... if the term isn't to enter the realm of the Caterpillar and his Hooka.'' '''Too late.''' ---- Soft (analog) requirements are fine -- as a starting point -- but need to be converted into something testable, which gets back to the LimitsOfUserStories, UserAntiStory, NonFunctionalRequirements topic. Functional or non-functional, you need to make your requirements testable. A ServiceLevelAgreement codifies (and contractualizes) the things that need to be tested, but only ''good'' SLAs are testable. So you can take your UserAntiStory and WriteItOnaCard as a bunch of testable constraints (whether or not they can be written as true stories). You can, of course, take some of these constraints and fold them into your existing stories. For example, you can extend each of your stories to say that it must happen within 3 seconds, or all relevant stories to describe large text fields as being limited to 2K bytes, unicode. But this violates OnceAndOnlyOnce. One commonality to Alistair's list of 5, above, is that all are GenericRequirement''''''s. Sometimes GenericRequirement''''''s can be referred to each of the specifically relevant stories or requirements, but as I said, this would violate OnceAndOnlyOnce. What we need, I think, are some patterns for testing GenericRequirement''''''s. See GenericRequirement''''''s for the continuation of this thread. -- RaySchnitzler ---- Requirement: The application must be password protected User Story: You attempt but cannot run the application without a valid password after other new functionality has been added this cycle. Point: If the security hasn't been put in then the task is to put it in. If the security was put in in an earlier cycle then someone has the task of making sure new stuff put in this cycle doesn't break security. This has to be done anew for all new functionality. Requirement: System in Java User Story: All new functionality added this cycle was created with Java. Maybe this works if you reconsider the customer and the project. There are levels of customers and there are projects both within and interconnected to other projects. In the above case customer might be the business owner who employs both the users and developers and the interconnected project might be Standardization on Java. The user interaction is the business owners paying for work. Software doesn't end or begin with a computer. -- DennisWillis ---- There are often requirements that do not come from "the user," but rather from other affected parties, such as the IT department. These types of requirements include specification of the standard desk top platform (CPU, memory, disk space, OS, etc.) to house your application, or specific interface protocols and formats for data sharing with other systems. This information is important, but it is unlikely to come from users, and unlikely to be in the form of a story. -- WayneMack ---- UserStories tell you what users want, not what they need. -- AlbrechtScheidig ---- Some months later, Alistair regurgitates redigested thoughts (ugh) ... (A) Index cards are wonderful. (B) The use of UserStory cards in XP projects is different than Kent's definition of UserStory in his writings. Get over it. (C) The utility of the cards in the Planning Game (i.e. so-called UserStories) is to size and prioritize work the developers are to do. (C) is the relevant bit, since utility is more what is to pay attention to. The developers have a limited amount of time, e.g. 120 work hours max. There are a bizillion things to do. By sitting with the customer and playing with index cards, they align their work effort for the iteration. E.g., How would you add documentation to an XP project? Customer names a chunk of documentation on a StoryCard, and it gets estimated and prioritized with the competing assignments. At some point, the documentation gets up high enough to pull someone off programming for some chunk of time, etc. (This discussion freely omits power struggles and vested interests involved in WHO gets to decide the value of documentation vs new functionality released, etc.). Similarly, if it doesn't take time from developers, it needn't go as a UserStory. E.g. 32-character field. Making it 32 characters doesn't take different time than 28 or 50 characters. So it doesn't make for a UserStory -- there is no negotiation over the priority of this work assignment. As I tend to say about many non-functional requirements, "write it down somewhere"... just not on a story card. It'll resurface in the conversations during the iteration anyway. As I currently see it, some of the cards in the Planning Game will be proper UserStories, some will be things that compete for developer time (WriteItOnaCard). -- AlistairCockburn ---- Are principles like Yagni or DoTheSimplestThingThatCouldPossiblyWork user stories? They certainly are part of every project. Yet they are talked about as principles and are not required to be acceptance tested nor are they broken down into constituent parts. A lot of requirements user stories are like that. ---- See CategorizingStories