Limits Of User Stories
Limits Of User StoriesThis 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,
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:
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 AcceptanceTests. 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)
Yes, you can put them on story cards. No, you can't capture their validity using AcceptanceTests. 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 EngineeringTasks 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:
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
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
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:
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.
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
-- 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 ServiceLevelAgreements 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 EngineeringTasks. 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 GenericRequirements. Sometimes GenericRequirements 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 GenericRequirements. See GenericRequirements for the continuation of this thread.
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.
EditText of this page
(last edited June 25, 2012)
or FindPage with title or text search