Comments on: Features vs Stories

By: Adrian Sutton

Adrian Sutton — Tue, 26 Jul 2011 06:31:04 +0000

Generally features break down into stories and then stories break down into tasks. The stories need to be small enough to fit into a single iteration, and quite often you can’t fit a whole feature in. By breaking the feature down into separate stories, you can deliver the feature incrementally and with some careful choice of breakdown deliver the value incrementally as well.

Tasks on the other hand should be about the minimum testable step you can take towards completing a story. On their own they probably don’t provide any business value and sometimes they will leave the software in a state that wouldn’t be ideal to release (a new feature without updating the user manual or a partly finished new dialog etc). You don’t want to leave the code broken obviously, but sometimes stories require one step backwards to make two steps forward.

By: Kai

Kai — Sun, 24 Jul 2011 04:09:09 +0000

Would it not be the same to have the feature and then break down the feature into tasks who will be assigned those tasks? why break the feature into stories?

thanks

Can u email me ur response. thanks

By: Ivan

Ivan — Tue, 21 Sep 2010 21:15:00 +0000

Hi Adrian,

I was giving some thought to this as well! I think your point of view is valid, although I would generally tend to break up User Stories (which represent the value added to the project from a business point of view) into one or many Features (which usually represent functionality).

Although, I think there is some occasions (like your example) when one feature (one functionality) may be big enough to break it up into smaller groups of tasks, that add some value by themselves, therefore having the case where a functionality is broken up into user stories, though in my opinion, this is not so common.

I used to think that there was a 1:1 relation between features and user stories, but after I took an agile programming workshop (that lasted a semester or so) we used the “break up user stories into features” approach, and this seemed to work pretty much fine.

By: Shimon

Shimon — Fri, 09 Apr 2010 14:34:37 +0000

Good summary, however I link a feature to a real business requirements. The questions that I ask is “what is the value added to the business by this feature?”

Do you think its valid?

By: Paul Eie

Paul Eie — Fri, 12 Mar 2010 07:41:05 +0000

Hi!
A great summary! I have been working with Scrum for a couple of years, but we have left out the distinction between user stories and features, and often ended up with the problems you describe:
* Too big user stories
* Many good work items
* But a problem to monitor real progress, as it’s hard to monitor how close we are to completion, as our user stories are too big!

I will definitely take this into consideration in our next sprint!

Thanks!

By: john

john — Sun, 10 Jan 2010 03:49:36 +0000

thank you for this. I wasn’t sure why features came first. I’m new to agile/xp/scrum, etc. and thought features and user stories was just double work.