Last Thursday we had a workshop in BestBrains about Agile Planning and Estimation, with some lively and interesting discussions on the agile methods of estimating and planning.
One of the question that we only touched briefly was how to handle customer requirements that manifests as interdependent long running stories.

In the agile literature the examples where themes (an overall picture of a functionality) are divided into user stories (As a ... I can) are almost always simple and straight forward, but as many of us has experienced this is more the exception than the rule.

A scenario could look like this: Several requirements from the customer seems to involve the development of a common component (one example could be a layer of abstraction to a legacy system), with a complexity not suitable for a 2 week iteration.

One challenge is to give the customer a good indication on how much each requirement cost to produce, since the implementation of the first chosen requirement will suffer the cost of making the common component.
Another challenge is to deliver customer value at the end of each iteration with a complex technical task.

One alternative is to present the customer with the following choice between three user stories (As a ... I can), using the story point-method to indicate the stories relative size and not how long they will take to finish.

1. Tech Story - 24 story point (As a developer I can ... creating the common component)
2. User Story A - 4 story point
3. User Story B - 4 story point

Any one of A and B would require the tech story be implemented first. But when done the two user stories should be fairly easy to finish. One might think that the customer does not need to chose which user story goes first because the prelude is given.
The danger here is that the implementation of the tech story is not driven by a customer need and the team could make an over-complex implementation of the tech story, since both the user stories should be supported.

Another alternative is to include the technical complexity in both user stories:

1. User story A - 28 point
2. User story B - 28 point

This yields a somewhat false picture one might say, because we know that the relative size would never be 48 story point for the two stories because the second would benefit from the first, and we just have estimated the total work to be 32 points.

On the other hand this is the more true picture for the customer - at this moment in time - because the relative cost are equal for the two stories and the size of 28 story point could be compared to other user stories not listed here.
The customers task is to prioritize between the two stories and chose the one he favors most. The user story chosen will drive the planning of the first iterations, perhaps taken out as a series of spikes or experiments, trying to shoot a bullet through the whole stack of the system. The team should force themselves to consider how the user story can be split into smaller user stories fitting into iterations where the team commits to 7 story point at the beginning of each iteration.
One could imagine the CRUD operations (Create-Read-Update-Delete) split up into iterations taken one at a time or perhaps a light weight implementation with a small entity, saving complex data and business rules for later iterations.
After each iteration the team will know more about the user story and more about the complexity of the component, and they could soon feel the need to re-plan or re-estimate the stories with this new knowledge taken into account.

This shows the principle that above an accurate plan we try to help the customer to make a decision from the cost, and emphasize the teams focus on working on small customer-driven tasks. We value planning over plans.

In my opinion breaking down a 28 point user story into smaller tasks would yield a different result than breaking down a 24 point tech story that is made to support several user stories.

Even if the customer cannot decide which story that should be implemented first, the team should make a choice and pick one of them to start with (preferably the most simple one to make a quick proof of concept and learn fast, unless any risks could be minimized taken a more complex one) again to keep focus on a user scenario when diving into the technical problems.

This all shows that planning is challenging and never straight forward, and finding alternatives can give you valuable insight on how to plan your work. I do not know which of the scenarios you would choose or if you could think of a third or fourth alternative to meet the challenge of interdependent long running stories or another challenging example.

By Jesper Thaning