best practices in creating a product backlog in scrum

Question

I am new to scrum, project management in general, and i am having problems deciding what to call a feature or a sub-feature (which are tasklists to creating that feature?) especially for the standard things we have in every web app.

So i am looking for best practices on how people are creating product backlogs for a typical website software (users, profiles, admin, front-end) .

I have this in mind as an example.

 - feature: home page

 - feature: contact us page

 - feature: admin panel
            - create user
               + create database (tasklist)
               + write stored procedures (tasklist)
            - delete user
            - add content
            - delete content

 - feature: subscribe 
            - create subscribe page

Also, how granular is too granular?

score 5 · Accepted Answer · answered Mar 25 '11 at 21:22

What we do is to have our top level be a "user story". Each user story should describe some specific benefit that the users will receive when the functionality is complete. Each story should describe a useful piece of functionality in and of itself. For example,

"Users can navigate to a web site to get basic information about our company."
"Users can use a web app to manage their subscriptions."
"System administrators can use a web page to add, delete, and edit users."
"System administrators can use a web page to add and delete content."

Tasks then describe the actions that need to be taken to ensure that the story is complete. For "Users can navigate to a web site to get basic information about our company," I might have things like:

"Create home page"
"Create 'Contact Us' page and link to it from the home page"
"Create 'Office Locations' page"
"Create 'Careers' page'
"Create navigation bar that links to office locations and careers pages, with space for future features"

continuing from where you left off, creating the "home page" has tasks in itself (sections, content, requirements etc) so is this too granular to be tracked? or it is left with the individual programmer to track this info? How granular is too granular? — tommy, Mar 25 '11 at 21:47
The rule of thumb is that tasks should be between 1 and 8 hours of work. If it is more than 8 hours (estimated), break it down more. Beyond that, you'll just need to try it and see what works for you. — Ethel Evans, Mar 25 '11 at 22:04

score 1 · Answer 2 · answered May 19 '11 at 03:43

You're over-thinking it. A lot.

Every Sprint, the Team is faced with the question, "What are we going to do this Sprint?". Ideally, backlog items need to be of a size that they can actually be completed in a single Sprint, and not so tiny that it becomes a nightmare to organize and keep track of everything. It's OK to have really big items that are low priority, then you split them into smaller items when they bubble up closer to the top of the priority list.

Features, sub-features, tasks. Who cares? As long as the Team is able to identify the top priority items each Sprint and get them done, then the PB is doing its job.

score 0 · Answer 3 · answered Mar 25 '11 at 21:43

I find stories are easier to define if they are accompanied with the steps on how to test it. The tasks are the things you would have to do to make that story possible.

The steps to test it are important as they help keep the story honest, set expectations about we're talking about without getting bogged down with the implementation. Generally, the stories should be really light so that they can be easily estimated and implemented with short a turnaround.

"Users can report a problem with a product or our web site" would have a description that contains high level testing thoughts, like "Navigate to the contact us page and fill out the form. Check inbox for thank you email." You can infer a lot about the tasks and requirements (you'll need to collect an email address and setup a mail server) but it's deliberately open-ended to drive the discussion with the client when it's time to estimate.

score 0 · Answer 4 · answered Mar 25 '11 at 22:08

Where I work we tend to have the following format for a user story:

As an X, I want to do Y because Z.

X = Actor wanting to perform some action. Y = Action to be done. Z = Reason for wanting this action so that alternatives could be considered.

Tasks are usually items that can be done in less than a few hours as I recall. Breaking down the building of a page depends a bit on what is in the page and the like as some pages could be seen as a simple task similar to other pages already built so that it takes less than 20 minutes to create the page and package up the changes to promote the change into other environments.

Part of Scrum to my mind is that the first few sprints are where velocity and break downs get worked out in terms of what works for the team as what may work for one team isn't likely to work for another.

best practices in creating a product backlog in scrum

4 Answers4