January 11, 2008

How Big Should a Story Be?

Our recent planning sessions have demonstrated two conflicting forces on story size. The need of customers to see business value and high-level plans pushes towards larger stories, yet the need for developers to be able to complete stories in a single iteration pushes for smaller sizes. I have researched a number of sources to understand more how Agile teams handle this conflict.

The most direct treatment of this issue is by Hai Ton, who in his experience report from the Agile 2007 conference says:

What would your Analyst team do when torn between meeting Customer versus Developer demands? When their needs conflict with one another, how do you appease them both? The report outlines the successful strategy one team used to decompose their Stories to serve both the development team needs to demonstrate progress as well as address Customer needs to see value.

His report describes that they used epics, stories and chapters. Epics are described in the form "As a ..., I would like ... so that ...". Customers were asked to sort epics into "must have", "should have", "could have" and "won't have" (MoSCoW). Epics were broken down into multiple stories.

Stories were individually written to be "independent", "negotiable", "valuable to customers", "estimable", "small" and "testable" (INVEST). Stories were described in the "Given ..., When... Then... " format.

Chapters were used when a story was too big for an iteration, and yet breaking it into two stories would no longer clearly demonstrate customer value. Their solution was to create chapters, and then to delay demonstrating the development work to customers until all the chapters of a story were completed.

There is a lot more good detail in this report (A Strategy for Balancing Business Value and Story Size, Proceedings of the Agile 2007 Conference, Hai Ton, ThoughtWorks), which unfortunately is not freely available online.

Here are some other discussions related to this topic that I found interesting.

 A related idea is a Minimum Marketable Feature. This term comes from Software by Numbers and describes a feature with clear business value that can then be broken down into stories in development. I haven’t read this book, but have been getting recommendations from so many people that I clearly need to get my hands on a copy.

Posted by bret at 12:01 AM | Comments (1)

January 05, 2008

My Writing Process

I've been using the Fieldstone writing method for years. I learned it from James Bach, who learned it from Jerry Weinberg. I've found it to be a great way to generate material, but have struggled over the years to organize the all the writing that it produces. Jerry recently published a book describing the Fieldstone method, but it hasn't helped me much with this problem. What has helped me are a couple of books by David Allen. In Getting Things Done, he describes a process for organizing and processing your email, to-do lists and all the reminders you need to accomplish your goals. I had to read it twice, about six months apart to understand it — it’s simple but deep — and initially used his method simply to organize my to-do lists. Like Weinberg, he encourages you to write whatever is on your mind. For a while, this only lead me to create stacks and stacks of cards. More recently I have learned about other GTD enthusiasts using #7 coin envelopes and floppy-disk binder sheets to organize index cards. This has really worked well for me. I've also recently read Allen's Ready for Anything, which expands on the principles and theory behind the GTD system. This has really helped me adapt it to my writing needs, because writing a book ends up being just another thing to get done, and Allen recommends that you put everything into one system anyway. I’ve also been helped by NoteLens, a simple, free tool for organizing multiple files that Jerry recently recommended.

Posted by bret at 05:59 PM | Comments (0)