With that in mind we are casting around for any hints on how to map out what we build and in what order. Chris Sims has some suggestions which may be useful, but I’m not sure they address our underlying problem.

InfoQ: Story Mapping Gives Context to User Stories.

InfoQ: Information Radiators: Is low tech really better?.

One such case is when a story is too large for comfortable estimation. Commonly this arises when a story is driven by a desire for a feature or sweeping change – something easy to give a name to, but complex in its detail. We have faced at least one of these most iterations.

Bill de hÓra discusses some approaches to tackling such large stories in a recent blog post:

Bill de hÓra: Managing large stories on agile projects

In our team we typically tackle the problem slightly differently. The items on our progress wall are represented by brown A5 envelopes, each with summary information (title, id, estimate) written in large, friendly letters on the outside, and an accumulation of detail (notes, time spent, diagrams, etc.) inside. To stop the contents falling out, the envelopes are all placed on the wall with the opening on the side.

Why do I mention this? We use a quick of this to deal with large stories. A story too large to estimate and develop on its own is represented by an envelope with the opening at the bottom. This implies that such stories can not accumulate detail of their own, but only reference other stories. We split the large customer story into several internal stories, estimate, annotate an develop them independently, but do not consider the main story complete until all the component stories are also complete. To show the relationship we write the ids of the component stories on the outside of the “vertical” envelope.

This approach seems to work. Stakeholders still have visibility of the status of the large story, and the development team is free to implement the component stories in parallel or in sequence, in whatever order is most effective and efficient.

Akshay Dhavle suggests the use of “finger charts” to get a better and more useful of project progress, in particular to help identify time-related problems.

Business Analysis: Finger Charts

• Reaching Hyper-Productivity with Outsourced Development Teams
• Pressure and Performance – The CTO’s Dilemma
• Agile Usability
• Web 2.0 Storytelling: Emergence of a New Genre

Martin Fowler has written about extending the idea of “technical debt” by including the concept of “interest”. Extra time spent on completing any given task compared with the time which would/might have been spent implementing that outcome on a cleaner system is effectively an “interest payment” on the “technical debt”. Noting an estimate of such an amount along with the elapsed time on each piece of work allows a relatively simple calculation of the total “interest payments”, and helps inform any decision to “pay off” the debt by refactoring, simplification, etc.

MF Bliki: EstimatedInterest

Stories seem a large part of our lives, and of the lives of everyone.

elearnspace: The Secrets of Storytelling: Why We Love a Good Yarn

The Secrets of Storytelling: Why We Love a Good Yarn: Scientific American

In our project we are currently working on an iteration where all the stories overlap and interact. Our usual approach is that each developer grabs a story and works on it until its done, then repeats until either the iteration ends or we run out of scheduled stories. In this case we need something a little smarter – some way of grouping the tasks for the iteration, regardless of which stories they “belong” to, so that developers can work on a chunk of related functionality rather than a story as such.

This is potentially risky, as some of the commenters on the above post point out, but at the moment I can’t see a way around the problem.

Should the Daily Standup Be Person-by-Person or Story-by-Story? | Mike Cohn’s Blog – Succeeding With Agile™

thekua.com@work » Automated story-based acceptance tests lead to unmaintainable systems

Update: here’s some more discussion on this topic, and how it is affected by the nature of user stories

User Stories are Just Schedulable Change

For the first time this iteration we have reached a situation where two stories were left incomplete at the end of the iteration. I could give a bunch of excuses about changing priorities during the iteration, but the point is that agile processes are supposed to be able to cope with this kind of stuff.

So now we are at the point of deciding what to do with these stories. Luckily, the guys at Elegant Code are also facing this problem, and discuss some options in a recent blog post.

Elegant Code » What to Do with Left Over Stories

In our case, the discussion is still proceeding. From an agile purity point of view the suggested approach of throwing the part-completed stories back into the pot for re-estimation, re-prioritisation, and re-scheduling is certainly compelling.