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.

Stories are not supposed to be, “1-2 days work”. Under Scrum stories are normally estimated using Story Points, a relative sizing system. If you use planning poker stories are given a points value – the time that story takes to implement depends on the velocity that your team has established.

If you feel the story is hiding complexity (you could call it an Epic story), you should break it up into smaller stories. Make sure that the new stories follow the INVEST criteria.

But you may be overengineering this; the XP principle of YAGNI applies here. To be explicit you should not implement a, “polymorphic tagging system under the hood”, unless you really need it. Even then, it should be designed by improving the existing system, that you have developed with a good suite of tests.

If you’re certain you do need this complex tagging system, you should call out the complexity in separate stories. Mike Cohn describes the approach to design as, “Intentional, yet emergent”

It seems that you are confusing stories and tasks.

User Story

A user story is a complete “feature”, something that when added to the product, provides more value to the product.

A user story should not be larger than it can be implemented during a sprint. During the first part of sprint planning, you decide which user stories you want to work on during the sprint. The goal of the sprint is to complete these user stories, thus adding more value to the product.

Task

During second part of the planning phase of the sprint, developers divide the story into tasks. The tasks are development tasks. They could be stuff like “Add column to database”, “Extend service x”, etc. A task should not be larger than it can be completed in one day.

During the daily scrum you evaluate the progress of these tasks. If a task has been in progress for more than one daily scrum, it is taking too long, and you, as a team, has the responsibility of resolving that situation.

Remember, user stories represent business value for the stake holders. The stake holders should be interested in the completion of the user stories, not tasks.

The task division is a tool for the development team to manage the sprint, to monitor progress of the user stories during a sprint, and to visualize potential problems.

The stake holders should not concern themselves with these development tasks. Unfortunately, it is my experience that they often do, particularly for organizations new to agile development. Dealing with this situation is a different matter though.

Epic

If a user story is bigger than you think you can complete it in one sprint, it is called an epic. It needs to be divided into several smaller user stories before you as a team can start working on it.

Remember that a user story adds value to the end user, so splitting an epic into a “front-end” and a “back-end” story is not the right way. Adding the back-end for a new feature does not in itself provide value to the end users.

Dividing an epic into user stories manageable within the time frame of a sprint is not always easy when you are not experienced with doing so.

Using Pivotal Tracker

I think Pivotal Tracker is a great tool for tracking user stories. But it is not a scrum tool as such, and the way that scrum teaches to divide stories into tasks is not easily handled by pivotal tracker. You can enable the ability to add tasks to user stories. But if you are running a project using scrum, I would suggest using a white board and sticky notes to track the progress of tasks during a sprint.

Having a design goal of implementing a polymorphic tagging system is fine, but you should still focus on implementing features the customer wants. This might mean that, fine-grained-User-Story by fine-grained-User-Story, your system evolves into having a polymorphic tagging system over time. At any point on that journey however you should have system made up of lots of small and testable features, described by a collection of User Stories you’ve implemented.

In this case it sounds like “Tagging Products” in your system might be an Epic, i.e. something which is far bigger than a single User Story and can be broken down into several smaller stories with a little effort. Taking a fair amount of artistic licence, I can think of the following User Stories which might be roughly applicable to your requirements:

• As a system administrator I want to seed the system with some valid tags so that users have some values to choose from when first using the tagging feature.
• As a user of the system I want to be able to search for a product by name so that I can tag it later.
• As a user of the system I want to be able to read the description of a product so that I can decide what tags it should have.
• As a user of the system I want to be able to see a picture of the product so that I can decide what tags it should have.
• As a user of the system I want to be able to attach a single tag to a single product.
• As a user of the system I want to be able to remove a single tag from a single product.
• As a user of the system I want to be able to attach a single tag to multiple products.
• As a user of the system I want to be able to attach multiple tags to a single product.
• As a system administrator I want to see a distinct list of tags in use in the system so that I can decide if any of them are duplicates.
• As a system administrator I want to consolidate duplicated tags.

…and I could go on.

I doubt any of these will be so lifelike that you will use them, but hopefully they illustrate the sort of detail you can go to with your User Stories.

If a User Story really cannot be sub-divided into any smaller stories and you still deem it too large to attempt to implement in one go, then you can split it into vertical slices. This is a technique which means delivering only part of the feature under each User Story, but each part being a testable slice through all the relevant layers of the technology, e.g. for a website this might mean changing the database, application and UI layers. Avoid having one User Story for the database work, another for application and another for UI, as these won’t be individually testable.

Taking even more artistic licence, I might split “As a user of the system I want to be able to attach a single tag to a single product.” into the following vertical slices:

• As a user of the system looking at a single product I want to be able to look up a list of tags so that I can decide which one to apply.
• As a user of the system looking at a single product, having decided on a tag to apply to that product, I want to be able to apply it.
• As a user of the system looking at a single product, having applied a tag to that product, I want a confirmation message on screen telling me that it has saved successfully.

Each of those is testable – if not particularly valuable in their own right.

There are books written for the sole purpose of finding out the correct way to describe and break down your requirements. So it is not an easy task.

Often times I find development teams striving for complex solutions instead of the most simple ones. This could be due to the story itself or because the team wants to go for an overly complex solution that not only solves this story but lays the groundwork for stories x, y and z as well. This is good intention, but bloats scope where the same job can be done with less work. It is always hard to judge how much design has to go into a story to not ruin future stories by messing up the design. This decision is for the team to make.

As a product owner you can only influence this by breaking down stories into smaller pieces. You should ask yourself: Is the story the smallest solution that we can think of right now? Can we break it down into reduced feature sets that some day will become the “big flexible tagging system I have always wanted”. You could start with a tag system for just a single tag, then extend it to include a list of preselected tags, and then let user define tags, etc.

For the dev team it boils down to: Can we find a simpler approach to realize the story, but still have a solid architecture that accomplishes the job today while not compromising future features.

If you are open to accept intermediate solutions and the development team also tries to offer the most simple, yet good solution then you will probably find the sweet spot in where the size of the stories you want to do is right (the smaller the better). This is not to say that you only have small stories. Some are bigger than others, this is just a fact that you need to accept, or if they are too big, then break down stories into smaller pieces.