Skip to main content

Managing "Effort" estimates

Last post 02:41 am February 15, 2013 by Sanjay Saini
2 replies
12:20 pm February 14, 2013

We're on our second sprint and am running into some difficulties managing effort estimations in both the product backlog and the sprint backlog.

We are estimating PBI effort in arbitrary story points 1-150 and sprint tasks in Fibonacci hours.

Two questions:

1. Should the PO gather the entire team during backlog grooming to estimate the PBI effort points or can he simply grab a subset of the team?

2. During sprint planning, we breakdown each PBI into tasks according to our DoD and use planning poker to vote on how many hours each task will take to complete. This goes smoothly and well. Once we start our sprint, the team often has to adjust the sprint board by adding tasks. How and when do we estimate the hours for the new tasks? Currently, we are not estimating hours for new tasks added to the board after sprint planning.

04:44 pm February 14, 2013

1. Scrum says that all PBI's must have an estimate. It does not prescribe when estimation must be done. Nor is "backlog grooming" a recognised scrum event, though something along those lines is meant to happen during the Sprint Review.

If you are doing estimation in a separate backlog grooming session then all team members should attend. If you aren't doing estimation, then the smallest practical subset of the team should be used. The goal of backlog grooming is to simply to facilitate upcoming planning sessions which all team members are expected to attend. If only one person is needed to groom the backlog (sanity check user stories, acceptance criteria, and feasibility) then only one person should be diverted to that task. The others should be working on achieving the current sprint goal.

As a side note, if I was SM I'd be nervous about allowing a PO "to grab the team", as it might set a bad precedent. The team has to manage its own work, and grooming sessions should be arranged in a way that is convenient for them, not just the PO. As an SM I'd see it as my responsibility to sort that out.

2. Update your estimates continually, along with the PBI's themselves. A scrum board should tell the truth in as up-to-date a manner as you and your team can devise.

02:41 am February 15, 2013

Here are my comments on your questions -

1. Ideally the complete team should be available for backlog grooming and putting the story points estimation against each PBI. The PO still owns the meeting but the timings can be adjusted as per everyone's convenience.

2. Tasks effort is not done using the planning poker, it is the remaining work which team should keep updating on daily, ideally it should go down with every day but it can go up too based upon the new findings. Team can add new tasks along with effort during the sprint execution. Your burn-down chart should tell everyone what is going on and where as a team you are.

Also before starting the estimation the whole team should have an understanding on the estimation model e.g. what does "X" story points means.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.