Frank Carver's Punch Barrel

We are currently trying to come to some conclusions about the “shape” of a new software product, and facing a whole lot of problems. Stakeholders are happy to argue for hours about relative priorities of individual features, but so far these exist in a vacuum without an overall vision of a product.

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.

We currenty use a wall, covered with brown envelopes, for story and task tracking. It has its advantages but prople, particularly people not based in this office, often ask for something else.  Chris Sims at InfoQ has a useful summary of the pros and cons of high-tech and low-tech “information radiators”

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

In theory, an agile story is a simple and obvious thing with many purposes. A description of some desired usage; a token for discussion; a prompt for acceptance tests; a grain around which to gather more detail. In practice, a story can sometimes be more like a traditional feature requirement, or more like a delivery contract. In these cases, estimating, developing, and delivering the story can provoke problems, risk, and conflict.

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.

We have a large project wall, on which paper/card stories, bugs and tasks progress from submitted through to tested. This is great for a quick view of state, but the physical movement of tokens does not help in tracking and analysing progress.

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

My browser is full of tabs, each representing something I intend to blog about. I need to clear some space, so here’s a few interesting links without comments.

• 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

We are currently struggling with how to integrate work on refactoring/simplifying/cleaning our product codebase with existing streams of stories and bugs. One of the tricky aspects of this is how to estimate and prioritise the cleanup work: how much is it worth, and how much time should we spend on it this iteration?

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

In my work as a software developer I mostly encounter stories in the form of “user stories” – a way of communicating about a change or new feature by describing it as a story. In the wider world, and in the other things I do with my life, stories play a much larger part. Stories form the basis of a large part of human communication and empower everything from watercooler gossip, through books and newspapers, to TV and games.

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

Mike Cohn raises an interesting and topical issue about how to indicate what you are working on at a daily stand-up meeting.

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™

A fascinating counterpoint to Gojko Adzic’s writings on acceptance testing in an agile process.

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

Back to thinking about stories in the agile software development sense.

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.

This time on the topics of storytelling in presentations

Storytelling 101

and in the context of “web 2.0″

50 Web 2.0 Ways To Tell a Story

At the moment, the company I work for is pressing forward on implementing an end-to-end agile approach to software production. With this in mind, I was intrigued to see an interview with someone who runs a company offering consulting and training in just this area, which they refer to as “industrial XP”. I found plenty of thought-provoking ideas in there.

InfoQ: Joshua Kerievsky about Industrial XP

The discipline of writing good user stories – ones which communicate clearly to all appropriate stakeholders, give enough information for effective discussion, yet leave enough freedom for innovative solutions – is surprisingly tough. Writing such stories for integration tasks is harder still. Shaun Jayaraj has some thoughts:

What to do? we are like this only: User stories in the Enterprise Integration space

Constructing sensible and effective user stories is a vital and sometimes surprisingly tricky part of XP-style agile software development. There are plenty of ways to choose a less than optimal story breakdown.

Lasse Koskela has put together a thoughtful blog post about this topic.

Lasse’s weblog – Ways to split user stories

One fairly familiar way of writing requirement stories is “as a … I want … so that …”. Elizabeth Keough reckons this is not quite right.

sirenian: RIP As a… I want… So that…