User Story Shield
User Story ShieldIn environments I've been involved in, UserStories are created by people who have some technical know how, even though they don't necessarily get directly involved with the code. Unfortunately, sometimes a person that does not know much about the system writes a requirement in the form of a design decision, a decision that doesn't fit naturally with the rest of the system. Similarly, if a requirement is made orally to an engineer, he or she may jump directly to the solution and write down only the associated engineering tasks, possibly missing a better solution along the way. Especially if several UserStories are related.
Therefore, I'd suggest building a UserStoryShield. A UserStoryShield is the same as the UserStory process except that it rejects any story that seems like a solution to a problem instead of a problem definition. The team would maintain disjoint UserStory and EngineeringTask collections. The UserStories will all be problems that need to be solved and the EngineeringTasks are all tasks yet to be completed to solve the UserStories.
One would use the shield like so, "I'm sorry, I don't understand how that's a problem with the system that needs to be solved. Could you please simplify it so I can understand it?" or even, "I'm not sure I understand the underlying problem that needs to be solved here." Also, you can use the user story process to prevent people from coming to you one-on-one and circumventing the normal CommitmentSchedule.
Not only do you keep perhaps insistent managers/users from interfering with your job ;), but you keep yourself from putting the cart before the horse. Also, by maintaining a complete and separate view of the system from the user's perspective at all times, the product doesn't necessarily get locked in a feedback loop with itself. You don't reject user stories even offhandedly because you just knew the system couldn't do it, and you don't fail to move the system orthogonally to itself when it needs to.
For example, say the general task is flying to the moon. Users generally are smart enough to have some technical know how, so they write as a UserStory, "A redundant backup air tank must be on the landing pod in case the first one fails." The engineering team would (politely) reject this and suggest, "The landing pod must always have a breathable atmosphere," as a replacement.
I submit this can become a subtle wordplay, but perfection isn't important. In the real world, the shield is used mostly in defense to refocus the whole project team (engineers to users to managers) on getting a useful product out the door when they've shifted focus to technical concerns.
However, it's important not to arrogantly reject technical suggestions from knowledgeable outsiders just because they are not on the immediate technical team. All suggestions should be taken into consideration just as if it was from your own team member because it may be valid. On the other hand, it's also equally rejectable if it doesn't fit or work, which is why it cannot be considered a valid user story because user stories cannot be rejected. For instance, in the above example, redundant air supplies is likely a workable solution to the problem, but it may be rejected if a solution like atmosphere recycling is better.
Finally, I can't say that I've ever tried this. I started to where I last worked, but my contract terminated and I was off to other things, so I don't know if this is a valid approach. I suppose in a perfect XP environment this is built in, but I'm not sure. I would appreciate thoughts, wisdom and pearls of experience. -- SunirShah
I wrote this in response to AlistairCockburn's list of user stories on LimitsOfUserStories. More specifically, to these two:
''The thing is to look for business value. Often there is some (but there is always a cost associated with it, the estimation of which is typically a technical question).
The first could have business value (very high value in fact) if existing legacy programs have a 32 character maximum. Cost: probably not very high, just build a simple string type ...
The second could have business value if there was intent to sell the source code or something similar. Arguably because of the availability of Java programmers, as well. Cost: perhaps time to implementation, perhaps compatibility with other existing apps. Most of the cost may come out in velocity.
This is about the distinction between users and programmers, isn't it? XP doesn't like programmers to preempt user responsibilities and here we're saying users shouldn't preempt programmers. I have a couple of reservations.
Sometimes what looks like a programmer decision isn't. I've known shops where I was told "use trendy technology so we look sexy to venture capitalists". At the time that meant Java and Internet-related stuff. I have no expertise on venture capitalists; it seemed plausible to me that the survival of the company could depend on such superficialities.
I am reminded of the problems you sometimes get using FunctionalProgrammingLanguages or LogicalLanguages?, which don't let you manipulate mutable state explicitly. The compiler is supposed to do all that for you. However, in the real world getting usable performance often comes down to the creative manipulation of mutable state - that's just how machines are. So you find yourself trying to coax the language into doing what you want without any way to express it explicitly. Like programming blindfolded and with gloves on.
What you are trying to do with UserStoryShield is like what the designers of FunctionalProgrammingLanguages do. The users are the metaphorical programmers and the UserStories are the language they metaphorically program in. The real programmers are the metaphorical compiler. The history of programming languages is people saying that there are programming constructs you shouldn't use - mutable state, "goto" statements, whatever. Here you are saying that "specifying Java" is a construct that doesn't belong in the language.
(Sorry - this probably isn't very useful.) -- DaveHarris
This is theoretically about the distinction between users and programmers, but more practically and cynically, this is about keeping managers out of the code and coders out of the account books. I've been told on many occasions to do this or that to the codebase, ultimately resulting a poor design because it just wasn't the best solution. Also, I've seen (and participated) in engineers making product direction decisions like we'll do this or that feature but not that one (a customer decision).
When your boss tells you to do something, you better do it, right? Well, I decided that was ineffective and because I (as a programmer) was responsible for completing the project on time with high quality and good scope. Thus, I decided to take charge of the situation.
When you decide to include or exclude a "feature," you can (and eventually will) fall flat on your face and possibly bankrupt your company because you don't have enough information to make those decisions. I refused to make those decisions because they weren't my responsibility.
Since this is radical thinking (do your own job!), I needed to build shields, ultimately culminating in the UserStoryShield. The shields were designed to keep low level decisions to people closest to the code, and high level decisions to people closer to the money.
RonJeffries suggested that if your boss says use Java, you either use Java or quit on UserStorySystemInJava. I'm not sure that's really true. I'm JustaStudent and I realized I didn't have to succumb to that. Maybe because I gave respect before I asked for it. -- SunirShah
EditText of this page
(last edited June 2, 2008)
or FindPage with title or text search