Hidden Story

Stories that the Customer has never written. Also known as BackgroundStories?.

But development with all its competence and best knowledge really thinks that this story needs to be done.


AntiPattern? There are more effective approaches that are completely ignored here.


When a development team follows this pattern, it is implicitly taking responsibility for the success of the project. This is dangerous because development teams rarely have the expertise needed to ensure the success of the project. A good development team can do little more than produce the software it is asked to produce; it is the domain of other people to insure that the requested software has business value.

If you do this, and thus start doing the business peoples' jobs for them, you have no right to complain when they start doing your job for you and inflict technical restraints (designs, toolkits, etc.) on your efforts.

Certainly, developers can often see a business problem coming, and they should bring that to the attention of the business people. But if you can't trust their judgment when confronted with these developments, you may as well flag the project as "doomed" and take appropriate action. You cannot succeed in spite of pointy-haired management. --RobMandeville


I wonder about the boundaries of this. A customer might have requirements like "system must be maintainable and supportable" that aren't expressed directly in stories, because they're vague. A seasoned developer might know that one way to make a system maintainable in the field is to implement some sort of internal logging scheme to provide visibility on internal states leading up to a failure or anomaly. (Having a good set of UnitTests won't necessarily protect you against a Microsoft Service Pack that gets deployed in the field.)

Is logging a HiddenStory? The customer didn't ask for it directly, and it may not bring immediate business value, and it might lower today's velocity. But it certainly isn't an AntiPattern. --DaveSmith


I am not sure the writer of the story is that important as long as the customer is involved in story selection. Users typically have more than enough request to keep everyone busy, but occasionally, the developers may want to suggest something that the user hasn't considered. If he likes, he adds it to a release; if not, it gets left in the pile. The key point is to not implement the story without user request.


EditText of this page (last edited December 19, 2002) or FindPage with title or text search