Story Dependencies In Xp

Should dependencies between user stories be managed?

Related Wiki Pages:

     BeyondExtremeProgramming
     PlanningGame

An example that comes to mind is a typical business application in which the customer asks for multiple reports for data summary. If the customer presents both stories at the same time, it will be quicker to implement the app funcionality first, then create the required reporting funtionality. If you work the other way around, you might waste a lot of time creating fake data for the reports so that they make sense.

Yes. When the first story is implemented, update the estimate on the second story. If both stories are picked for one iteration, thank your lucky stars and refactor more.

A related issue is as follows - you have a number of stories which appear to assume common functionality, e.g. "Show the report generation wizard dialog with relevant options set to sensible default values, then output Death Star Megadeath Statistics Report"; similarly for N other Reports.

Should the common functionality be factored out to a distinct story, which would probably need to be scheduled first ?

Also, is the repetition in itself a possible sign of a problem with the stories ? This actually showed up in estimating a project which, sadly, or fortunately depending on point of view, never made it past the "fuzzy front end" stage. The actual requirements I have in mind were not XP stories. I was helping out a junior project manager who had difficulty making sense of the job and offering various bits of XP for consideration - we tried to cut up the requirements document into story-sized chunks, with middling success. I now suspect that you might come up with wholly different versions of your "requirements" depending on how you formulate them. I'm not sure whether that should be bothering me or not. -- LaurentBossavit

Customers are not usually stupid. They won't usually ask for things in inherently wrong orders like reports first and then data.

Estimate related stories with two numbers 5 / 2. When asked what it means, say "The first one of these you pick will be 5. All the rest will be 2.

And reestimate often. Did the first report you did, or the second, make subsequent ones easier? Then grab all the reporting cards and reset their estimates.

Nothing to it, really ...

moved here from PlanningGame

other moves? Players? Goals?

One we've found useful at prior employers:

MotherhoodStory. Development looks at a UserStory and sees it's just the tip of an iceberg. The UserStory, or the principle it embodies, is declared to be a MotherhoodStory. Developers suggest several UserStories that the MotherhoodStory generates and tell them to Business. Business thinks hard and returns some or none of them as real UserStories.

Important idea, and I personally like the terminology. Some kind of hierarchy and/or network of UserStories seem vital to me from past experience. Except in the olde days we didn't used to call them UserStories but SuccessStatement's (sorry). These have definitely needed to be both decomposed and inter-linked through "solves" relationships in the early stages of customer discussion and development.

It's a key matter of judgment to know when you have enough coherence in the system vision and enough detail in the 'leaf' stories to get on with implementation at least of the SpikeSolution sort. TomGilb's rule is: some time in the first week is fine. Sadly, this doesn't leave too much room for BigDesignUpFront! --RichardDrake

Some mention needs to be made of dependencies between stories. That can constrain their reordering. Also stories can require resources not under the control of any of the players (as when you need to buy new hardware or system tools which won't be available for another 2 months). -- DaveHarris

One of the lessons I learned from ChryslerComprehensiveCompensation was that I could ignore story dependencies for planning purposes. This came from two sources that I could identify. First, Business never asked for irrational stories, like insisting on reports even though they didn't want the stories that created the data on which the reports were based. Second, doing business value first meant that you would naturally do "Basic Paycheck" before you did "Enhanced Paycheck", since the basic one was far more valuable than the enhanced.

I'm not sure this lesson is generally applicable, but it certainly proved so for us. And it is SO much simpler not having to track dependencies...

I think what happens is that most dependencies amount to a lot of little things waiting on one big thing: "we can't do any of these until we get the new server". People seem to manage these just fine informally. -- RonJeffries

The point about external resources is well taken. My general strategy is to cut back on requirements until there are no more external resources, or to pull them into the team. If this isn't possible, you would have to do something to manage them. Please suggest additional rules, pieces, and players. -- KentBeck

Kent-- see what I did to Estimate Stories above, regarding LoadFactor, which we haven't mentioned here. -- R

There is the issue of data modelling, too. I can see this as perhaps a standard, built-in "user story" that all database applications must include. Going with the XP principle that it doesn't need to be complete (it gets fleshed out anyway throughout the various releases and iterations), but so much can be learned about the business system being modelled from doing a more-or-less complete data model, that I'm wondering how to incorporate this into the planning game. As a database application programmer, I also see the data model (and the physical database) as the foundation upon which the rest of the system rests.

While engaging in an e-mail discussion of this issue with AnthonyScilipoti?, I realized that the data model/database can be thought of as an object with the absolute worst, most tightly coupled API that you could imagine - one that none of us would ever intentionally create. This makes the entire system subject to instabilities introduced by even modest changes to the database schema. -- SteveSawyer

Each story should take no more than 3 weeks of ideal time to implement or else it is too complex to plan and build and should be split into two or more simple stories. How do we do this when the story is already on the most simple level that 'Business' wants to understand? For example the system I'm working on has a whole lot of database and interprocess communication that is pretty much a requirement of the first piece of actual functionality. It would take more than three weeks to build that, but a user story needs to do describe a piece of useful functionality, not building the infrastructure doesn't it?

-- It may be that the infrastructure counts as ToolsAndLibraries?. Thus, you, the programmers, are the clients of that SubProject?. That you may also be the providers is an interesting exercise in reflection and introspection. Thus, maybe you could run the highly technical up-front work as a separate SubProject? that you specify as (technical) users. Unfortunately, the scheduling and implementation of something like ToolsAndLibraries? isn't as amenable to ExtremeProgramming as a vanilla business system.

For more XP implementation issues, see ExtremeProgrammingImplementationIssues