Breaking down a complex story at project start

scrum

I'm trying to get to grips with agile project management (with Pivotal Tracker) but keep finding myself running into walls when trying to define the first few stories of a project. Take for example this very simple story:

"A user should be able to tag a product"

Assuming I've already defined "product" elsewhere, this story would possibly involve writing a polymorphic tagging system under the hood, on completion of that system id be able to finally add the ability to tag a product.

My problem is with the amount of work hidden in this story. I can define tasks to get the story done but stories as a whole are supposed to be 1-2 days work? I don't feel right about the story just revealing the tip of the iceberg but that's the only part that relates to the User.

How do you overcome this kind of thing? What are the best practices?

UPDATE 25/08 Thanks to everyone for your guidance, I've taken all advice onboard on how to define stories. I am now switching to Jira Grasshopper which has better support for tasks within stories (assignment, estimates etc) and tracking of development tasks once the sprint has began.

Best Answer

If you need your stories to be 1 to 2 days of developer work each, perhaps you should break each story into specific user tasks that are 1 to 2 days of developer work.

Consider the following "user story:"

A user should be able to receive an invoice from a purchased product.

Think about what's involved just in the database design, in giving the user this capability. You need a customer table, an invoice header table, and an invoice line items table, and we haven't even talked about accepting payments yet.

In reality, user stories are not this simple. Complete user stories include a walkthrough of the user steps involved:

  • User puts product in cart
  • User specifies quantity
  • User specifies shipping type

and so on. In short, you need to break down your user stories into finer detail.

Related Topic