User Story System In Java
User Story System In JavaAlistairCockburn asks, on LimitsOfUserStories:
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.
He then offers as one example:
"The system will be implemented in Java." (generic programming standard requirement)
This one is a great example. When I got here, I was completely convinced that it had no aspects of UserStory, and the short answer was: You're right, it isn't just like a UserStory because it can't be estimated and doesn't have tasks.
Teams I know have automatically just taken stories like this, written them on cards and put them in the UserStory pack. Sometimes they're called "Background Stories".
When scheduling time comes the card may serve as the focus for discussion, often of business value or risk, often of some specialized tasks such as picking a compiler or Jack and Jane taking a Java course.
The value and risk discussions clarify why we want to be in Java, and what problems could arise since we're all COBOL programmers. The tasks may go on the board and get signed up for, or someone may pick them up as overhead. Tracker knows to keep track of whether they're getting done.
I've seen several teams just go ahead and write the things on cards and get on with it. My inclination at this writing is that while they are clearly different in some philosophical way, they're not different in any operational way.
In short, treating this requirement as a UserStory won't work in theory, but will work fine in practice. Write it on a card, discuss its value and risk, generate tasks from it if it has any, and move on.
UserStory is a special case of WriteItOnaCard.
I think that your comment, "Write it on a card, discuss its value and risk, generate tasks from it if it has any, and move on." (emphasis mine) is key to the disagreement we seem to be having. Among the requirements that Alistair has listed, it is not clear to me that all can be satisfied fully by simply generating tasks. There may be tasks, but the major impact of these requirements is in the background, and may act as a constraint to many seemingly unrelated tasks. In that case, you cannot simply "move on" after deciding that you have generated tasks for it - you may have to consider its impact on every other task in the system.
In the best of all possible worlds, you may be able to ignore its impact until later, and then do some optimizations (especially for performance requirements). But you cannot always be certain of this. As a trivial example, it is not cost-effective to ignore a requirement such as "build it in Java" and then refactor a Smalltalk implementation into Java. Similarly, if you have ignored a requirement for internationalization, it can be very expensive to add it after the fact if you chose to DoTheSimplestThingThatCouldPossiblyWork and hard code all strings within the classes that use them.
Some of these requirements do necessitate up-front work, including the selection of standards ("all strings are to be requested from a message class, thus allowing them to be changed without modifying the code which uses them") or architectures ("state is passed to and from distributed objects via serializable value objects, and cached on the client as needed"). If you treat them as ordinary stories and don't consider them until the iteration in which their implementation seems of particular value to the customer, you may discover that the retrofitting of standards or architecture is prohibitive. -- RussellGold
Or you may not discover that retrofitting is expensive. Another strategy is to focus on what the business thinks they need and trust your ability to refactor.
This must be from someone really good - it says a lot. Think about it.
Among the requirements that Alistair has listed, it is not clear to me that all can be satisfied fully by simply generating tasks. There may be tasks, but the major impact of these requirements is in the background, and may act as a constraint to many seemingly unrelated tasks. In that case, you cannot simply "move on" after deciding that you have generated tasks for it - you may have to consider its impact on every other task in the system.
Lots of things already constrain seemingly unrelated tasks. The team will generate conventions all the time and then promulgate them and follow them. They have to do that to function. Please say more about how the constraint "Use a Message class" seems so different. Thanks -- RonJeffries
I'm not positive that I can express it well at this point, so I may just be thinking out loud here. I have understood XP to generate tasks from UserStories. Standards and conventions typically come from discovering a good way to do something. That is, they are patterns which have proven themselves. Initially, you don't tell people *how* to solve a particular problem, but let multiple people try different ways until one superior solution emerges - then you apply it where ever appropriate, letting people know via a TechnicalMemo. But these are simply lessons learned while implementing functionality. Of course, you usually do not apply it everywhere immediately, since it is just a "better" way to do something, not the only way.
To a large extent, the order in which you implement orthogonal functionality should not matter too much, since each one does not typically have a lot of effect on another. Interrelated functionality may be different, as adding a new related function to the system can necessitate some refactoring to make it fit. Now, the internationalization requirement necessarily affects all user-perceivable functionality. If you do it in the third iteration, you will have to modify every single UI put in the system in the first two. As a result of that, you may well discover the message class constraint, but it is one that will *have* to be retrofitted throughout the system, unless you are willing to live with a multiplicity of mechanism that must be controlled from a single point.
To avoid this, you are probably well-advised to select such a task in the first, architectural, iteration - even though it is not a feature that the customer needs in the first cut of the system. And even then, you are probably not going to call out engineering tasks from it, but simply conventions which you hope will ease actually implementing the requirement later. This is another key difference. Most UserStories seem to be built in a single iteration. UnitTests and FunctionalTests ensure that they continue to work through later iterations. Requirements like internationalization are different. At no point can you say - this story is done, all I need now is to keep it from breaking.
Does this make sense to you? -- RussellGold
I think you can pretty easily do regression tests for internationalization. Just do a static analysis in of your code for naked strings. If a string doesn't contain English, flag it so that your static analysis tool won't complain. I'm planning on adding a check-in script do to this once I get around to doing I18N on JeraWorks.
BTW, I'm perfectly aware that there are other aspects of I18N (icons, color schemes, date, time and number formatting) but in my experience factoring out the strings is 90% of the battle. -- JohnBrewer
Remember, XP is not just UserStories. The PlanningGame is only the middle scale of a three-scale system, where the inner scale is IterationPlanning, and the outer scale is the project lifecycle (well documented in chapter 21 of ExtremeProgrammingExplainedEmbraceChange but not, apparently, on Wiki). The best time to choose a language would be in the ExplorationPhase of the project as a whole.
That said, I don't really see why UserStorySystemInJava is so problematic. The rules of XP's PlanningGame say that Business can drop new stories on Development's lap at any time. Now, "do it over in Java" is a big honkin' story to dump on Development, but it's perfectly within the rules. Development then estimates the story, and Business gets to re-prioritize. Depending on how your UnitTests are set up, you may be able to use the old UnitTests. -- JohnBrewer
I'm confused. How is "The system will be implemented in Java," a user story? Why does the user care what implementation language you use? That's an engineering issue. -- SunirShah
Real world example: When I was at Autodesk they had a mapping product called MapGuide? that ran as a browser plug-in. Business decided that they needed a version that ran as an applet. So Development forked a team (which I joined) to rewrite the C++ Win32 plug-in as a Java applet. -- JohnBrewer
I still don't understand this. Business decisions like this are made to surround the product/company in the appropriate buzzwords unless your end users are programmers (e.g. you're writing a third party library). However, if they are not natural technical requirements of the product (which is likely), I've found they are very bad (low return on investment) decisions to enforce. Especially since they will change quickly with the next fad. If you're forced to do it, all right, that's out of your hands, but it's still not a user story, it's an engineering task. If it's really a loose jab at expressing a real user story, like "The product must simultaneously run on diverse platforms," then rewrite it as such because you can then focus on solving the actual problem. I've learnt that it's best to reject "feature requests" in the form of solutions instead of problems-yet-to-be-solved. Part of that uncrossable line between managers and engineers that I respect. -- SunirShah
I think UserStorySystemInJava is mostly a ContrivedExample?. Other than the case I mentioned above, I've never heard Business dictate platform, at least not afirmatively. In my experience, it's usually the other way around -- Development eager to try out some new unproven technology, Business wanting to know why we can't just use the thing that worked last time. -- JohnBrewer
Unfortunately, now that I think about it, even I don't think it's a contrived example. Where I used to work, we kept being told to use XML. XML was the answer. No matter how many times we explained that XML is just a way of storing data and that it was very little to do with a given problem at hand, they insisted on using XML even when it wasn't appropriate. This lead to some poor designs because it was unnatural. I think UserStories are an attractive way to resolve this problem because you can reject stories that mask themselves as precontrived solutions instead of problems for you to solve. (That is not to say you can arrogantly ignore technical suggestions, but they are not requirements per se.) -- SunirShah [P.S. In my ex-company's defense, using XML was a very legitimate technical suggestion to replace our SQL database. However, the failure was not trusting the JustaProgrammer-s who were going to implement the system.]
Question for you (who? JohnBrewer or SunirShah?):
"Wouldn't it be a valid user story that the product must behave the same way on HP, SUN, WINNT, and SGI?"
I'd say, Yes!, it is a valid user story because it cannot be rejected on grounds there is a better solution. That is the problem to be solved. Problems can be technical. And problems (and by extension UserStories) can never be rejected.. only solutions. -- SunirShah
When it comes down to it, Business can set any constraint they want. Believe it or not, in some companies, they require that everyone wear weird colored strangling cloth ropes around their necks. If they say program in Java and won't change their mind, then program in Java or get the hell out. It doesn't take a new process element to deal with "program in Java". You just do it. -- RonJeffries
In my case, the user story is "We want this application to run on both Windows and Macintosh, and we're not going to give you enough time to re-implement the GUI on the second platform." So Java for the GUI. Yes, I know there are cross-platform frameworks available in C++, none of which I'm happy with. -- KeithRay
Of course, then there was a headache in educating the customer that, just because an application is written in Java, doesn't mean it can run in a browser unmodified.
I did some work for a company which had a suite of interacting applications written in Java, PRO*C, C++, Visual Basic 4.0, Visual Basic 5.0, Visual C++, Prolog, Cobol, PL/SQL, CA-OPENROAD. I think if that company had had a card which said 'This program will be implemented in X', for any (single) value of X, then the company may have been a lot healthier. And the support team would have been a lot happier.
I think that saying 'You have to use X' is a perfectly valid thing for a customer to do. You can always try and disuade them of course, but you have to accept that there may well be other constraining factors. Trying to get a cohesive build of the above was a nightmare (I was part of the support team). -- MatthewFarwell
EditText of this page
(last edited December 5, 2005)
or FindPage with title or text search