Storypoints for product backlog estimation, hours for sprint planning?

[James Birch]

Storypoints for product backlog estimation, hours for sprint planning?

Hi,

I just completed a scrummaster training course. The trainer recommended using storypoints for product backlog estimation and then switching to task estimation in hours and capacity-driven sprint planning (using the velocity as a sanity check).  

Does JIRA supports this? If so, how should I configure JIRA?

Many thanks,

James

[Ste]

Hi @James Birch

Just to clarify you'll have:

• A Scrum Board with a backlog of stories to complete, sized in story points
• Sub-tasks created under stories in the sprints (active / future planned)
• Hours estimates on the sub-tasks
• Time tracking on the sub-tasks (i.e time spent against the original estimates given)

^ It's not an unheard of approach - but boards usually taken into account one type of estimation, which you can set via the Board Configuration under "Estimation".

So this means you could have either/or on one board - not both. The sub-task estimates do roll-up to story level but as a summary (Remaining Sum) rather than an estimate, which is still set at a story level.

There will be a way of doing this - but I'd suggest keeping it simple:

• Story Points or Time for stories
• Use this estimation type to plan sprints
• Set time at sub-task level but just for tracking and reporting purposes

Ste

[James Birch]

Thanks Ste for the info. That's what I thought, but not what was recommended. The trainer also recommended stopping tracking actuals and just working from Done tasks and velocity.

I suppose we could:

Use Storypoints for estimation and velocity.

Use original estimate or remaining estimate for assigning tasks (with storypoints as a sanity check)

Stop logging work completely and use velocity for all planning.

Or will that not work?

[Ste]

Possible? Sure - not sure I see the value though.

If you're going to estimate sub-tasks in hours to use in planning - I'd suggest the actual time spent is equally as important - otherwise, how will you know if the estimate was near accurate? How can you retrospect if your sprint planning was a success or not?

I'm also a little weary of considering story points and hours during planning - I'd usually advise doing just one, to avoid a scenario where story points become based off time. 

Story points are based on the Fibonacci scale to both have teams think harder around the complexity / effort of work and it helps to avoid points equalling hours (eg. 1 = 1 hour, 2 = 2 hour) unlike in a more linear system (eg. 1-10). 

Ste