Product backlog- when do task hours get estimated?

Question

I am wondering if when developing a product backlog do tasks have hours estimated for them. To confirm, i can talking about a product backlog here not a sprint backlog as I know it does have.

Answer 1

The preferred type of Product Backlog Item for a Scrum team is a User Story not a task.

User stories are usually estimated in Story Points. There is no set point at which to estimate a story.

Scrum teams use Planning Poker to estimate stories, which most teams usually do shortly after the initial backlog is created. As new stories are generated through out development, teams tend to run Planning Poker to estimate those stories once per iteration. Some teams don't even estimate at all and just count the number of stories, although this relies on breaking stories down to a fine granularity.

The time which Scrum teams normally create tasks is during the Sprint Planning Meeting. The team create the list of tasks necessary to delivering all the selected product backlog items. Each task on the sprint backlog is also usually estimated.

As with user stories, I've seen several different techniques used to estimate the work required. Some teams use story points, others use "ideal man days". Some teams again don't bother and use the number of tasks. The purpose of estimating these tasks is so that you can keep track of progress within a sprint and as a secondary check (to the story points) that the team is not taking on too much work.

I never really have tasks on the product backlog, I normally would keep them within a Sprint. However, I have previously added Spikes to the product backlog. However, they aren't really estimated - they are time-boxed, meaning you set a time limit which you do the work within. A Spike is a kind of information gathering exercise, the code that is created is intended to be thrown away. After the spike, you usually use the information it has gathered to create some stories that can be estimated in the usual fashion.

Answer 2

I don't really use hours to estimate the product backlog, as often it's in a language that doesn't readily lend itself to hour estimates (And ideally, that's what the sprint backlog should be for, as I understand the process).

We use the points system (or rounded Fibonacci if you prefer), and scale the tasks by complexity. Such as "Ok, user A wants graphical representation of these elements", and through experience, you know that can be tricky but not not time consuming. If a 1 is easy, and 21 is complex, it might be a 4. User B wants an interactive graph that can be changed on the fly by adding/subtracting data points/business units. That gets a 15.

Also, don't feel like you absolutely HAVE to detail points for all of your backlog. Some items may never be gotten to. Do enough for the foreseeable future, and work from the top down as it is (or should be) already in priority order.

You also have to consider the ROI, in that a 3 task may be quicker than a 5 task, but the 6 task will produce X% more revenue. Is that enough to bump it up? You have to decide.

Answer 3

Usually it is too time-consuming to estimate hours for items in the backlog. Your team can spend time for hour estimation while this backlog item may never make it to the top. Thus usually only those items that make it into a sprint- are estimated in hours while being split into smaller pieces for sprint tasks.