There’s a lot of confusion about the difference between User stories (in Agile) and Tasks (in Waterfall and other development methodologies). Adding to the mystery is the seemingly arcane methodology for breaking down functionality into user stories. These are surely the questions I’m asked most, especially by folks just jumping into Agile, and they’re really not as difficult as they seem.

User stories and tasks are actually pretty much the same thing at a functional level. You want the functionality identified in manageable bites for both tracking and implementation, no matter what methodology you’re using. Too small and you’re spinning your wheels; too large and you really have no idea how far along you are. There is a difference between methodologies in the impact of getting the functional bites the wrong size: in Waterfall, bites that are too small have more impact on the project schedule itself because of the increased time required spent tracking and reporting; big bites mean that it’s nearly impossible to get an accurate status but may this not impact the project schedule. In Agile, bites that are too small are annoying but easily dealt with; more than a mouthful means that you’ll be dragging user stories across sprints and missing significant efficiencies as you fail to take advantage of opportunities to have several people working concurrently on high-priority pieces of functionality

The ground rules in either Agile or Waterfall development for a user story or a functional task are really the same:

• A user story/ task should be a functional entity that hangs together to form a whole (the whole may be a piece of a bigger picture).If for instance you’re implementing a customer tracking system that has ‘add customer’, ‘modify customer’, and ‘delete customer’ functionality, each of those would be a user story or task.Individual fields for each of those functions (‘enter the customer name’) would be too small; lumping all of these together would be too big.
• The user story/task is appropriate for one person to implement.If two people can work on the task/user story at the same time it’s too big and should be tracked as multiple tasks.
• If user story/task is a baseline that will look or perform in a similar manner to other user stories or tasks it needs to be separate – you don’t want to set these up in the same task (see above), you want to get the baseline established and then use it as a jumping-off point for the other similar tasks.

It’s important to keep all the history of a single functional implementation in one place for audit trail, tracking, risk minimization, and the ability to see the history in one place should anything arise. Additionally, in any development methodology it is critical to document the dependencies between user stories or tasks to avoid the time, confusion, and rework of starting a task without all the prerequisites in place.

Past the functional level there can be a significant divergence in further task breakdown (waterfall typically starts to break into code or code segments (I rarely go lower than a functional code segment because the tracking overhead rarely has a positive ROI; depending on whether the teams are co-located or geographically distant, many agile implementations don't break the user story down further than this functional level), but that's a different discussion and the results can vary widely from implementation to implementation

It’s easier to get your bearings in an Agile environment – jump right in and it will become apparent which user stories are the wrong size. It’s a little harder in a Waterfall environment because adjustments are more costly, so spend a little time validating the task breakdown before you finalize the schedule.

Happy breakdowns!