Features vs Stories

I realized today that I hadn’t made explicit the difference in my mind between features and stories and it’s an important difference. Essentially, a feature is a group of stories that are related and deliver a package of functionality that end users would generally expect to get all at once. For instance, inline table resizing is a feature (note: this is the ability to drag to resize tables, rows and columns – try it in Word). In the first pass, you’d probably have a single story for inline resizing of tables, but it would be too big to estimate. So you break it down into three stories, resize columns, resize rows and resize the table itself.

Now we have three stories – three things to develop which add value to the product and can be done fairly quickly (we’re currently aiming for the biggest of our stories to take a day). There is value in being able to resize columns but not rows or the table itself – it allows users to distribute space between columns more easily to make the table look good. In fact, it covers 90% of the use cases for inline table resizing – people rarely resize the overall table or the height of rows, usually they just want to make column widths fit the data better. Despite that, shipping just that story out to users would cause confusion and complaints to support because it sets up the expectation in user’s minds that they can resize tables so why can’t they resize the rows or the table?

The feature is all three stories put together, and to be able to ship without confusing our users we really want to make sure all three stories are completed before we ship – however we can still release to internal users as part of our dog-fooding program or to beta testers before we have all three, so there is value in doing just one of the stories.

There are two key advantages to breaking down features like this. Firstly, it makes estimation easier and more accurate – things that take a long time tend to be very difficult to estimate. Secondly, it allows us to track progress on the feature accurately. One of the first rules of tracking project progress is that you only ever track tasks complete, and not partial tasks because people are really bad at estimating how close to completion they are. With small stories you can track progress just based on the number of complete stories without losing too much accuracy.

Breaking down stories is pretty hard though because you have to make sure that they still deliver value. We had one story recently to develop a particular properties panel that would become part of a larger dialog. Unfortunately we were given the panel story before the overall dialog story so we developed a panel that the user couldn’t possibly access. Worse still, we wasted time beginning to create a dialog just for that panel because we assumed it was required – we should have picked up on the lack of value in the story and asked the client about it before we started work – we probably would have done the create the dialog story first, thus making the panel story suddenly have value.