9

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.

matthewrk
  • 263
  • 1
    Breaking up work into tasks which are at most 1-2 days' work is definitely a good idea, and a lot of people would say it's essential. However, tasks != user stories. Tasks are the discrete bits of development you need to do in order to fulfil user stories, and a single user story may comprise many tasks. – vaughandroid Aug 22 '13 at 10:01
  • 1
    @Baqueta But its the story that has the estimate in points? and those points are tracked as team velocity, at least that's how its setup in Pivotal Tracker. – matthewrk Aug 22 '13 at 11:20
  • The user story is done when all the tasks required to fulfil it are complete. If you end up splitting a story across a couple of sprints it might throw off the velocity a little for those particular sprints, but it comes out in the wash and your average should still be useful. – vaughandroid Aug 22 '13 at 11:34

5 Answers5

7

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"

Dave Hillier
  • 3,948
  • I didn't see your edit. Your original version basically said "don't do it," which I felt didn't add any value. Presumably the "polymorphic tagging system" is part of the requirements. I've edited to de-emphasize the "overengineering" aspect of your answer, and changed my downvote to an upvote. – Robert Harvey Aug 21 '13 at 16:29
  • I still stand by, "don't do it" :). Scrum is a specific methodology that the OP would be going against Scrum principles. – Dave Hillier Aug 21 '13 at 16:32
  • Thanks for the link on planning poker, I had used a similar system to that before without knowing there was a formal procedure.

    The reason that I specified a polymorphic tagging system is because I know from the outset we will need to tag other models too, so in that case it should be considered from the start?

    The 1-2 days work per story thing is just something I picked up as a "good idea" when researching scrum, working on points of effort or difficulty alone seemed to be a bit open to interpretation where as estimating a days work seems fairly accurate.

     – matthewrk Aug 22 '13 at 07:58
  • 2
    @matthewrk That's what YAGNI is about: Don't even try to make a full polymorphic tagging system yet. Make a simple one for the one specific use case. If the product owner comes back with another story about tagging other things, then you extend the simple existing system into a polymorphic tagging system. Just because you think it will be necessary doesn't mean for sure that it will be; it may turn out that tagging other models won't be needed for a while, then everyone forgets about it and it never becomes a requirement. Hence, "You Aren't Gonna Need It". – Izkata Aug 23 '13 at 03:43
7

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.

Robert Harvey
  • 199,517
  • Can you give any breakdown examples based on my story? The reason I struggle to break it down further is because tagging is a very simple story on the surface, and its the only part the user touches. – matthewrk Aug 22 '13 at 07:53
7

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.

Pete
  • 8,956
  • 3
  • 42
  • 53
  • 1
    Thanks, this is definitely clearing some of the workflow up for me. When developers divide the story into tasks, do they create more stories to track those tasks? or add tasks to the story? Trying to work out how to apply this in Pivotal Tracker. – matthewrk Aug 22 '13 at 16:10
  • The developers do not create new stories. The stories are managed by the "Product Owner". You could say that they add tasks to a story, but I think that phrase is a bit misleading. I added to the answer some words explicitly about Pivotal Tracker. – Pete Aug 23 '13 at 07:26
4

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.

Nick
  • 1,175
  • When you mention tests, is that from a users perspective? i.e. integration/end-to-end tests? Given your example stories as a developer might I take all of those stories, implement the structure I needed (polymorphic tagging) then complete all the stories at once when id fulfilled the user side of the requirement? but then where is the overall technical requirement tracked? – matthewrk Aug 22 '13 at 16:32
  • In this case I mean testable by a user, so that the actor mentioned in the User Story can verify that you've implemented what they want. – Nick Aug 23 '13 at 10:59
  • There is substantial value to having one currency on a project when talking about requirements. Everyone talking about progress in terms of User Stories makes communication and reporting far simpler. I would recommend you agree a set of User Stories with your customer and work on them in an agreed order (most business value first, except where there are technical dependencies) rather than just implement your vision. If you think additional features from your vision of a polymorphic tagging system are valuable, then raise them as User Stories and agree with your customer when to do them. – Nick Aug 23 '13 at 11:18
2

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.

malte
  • 519
  • 2
  • 9