Skip to main content

Estimating product backlog items

Last post 04:47 pm January 4, 2016 by Timothy Baffa
13 replies
07:37 pm June 30, 2015

Need some clarity and opinion from other practitioners on timing of estimation. So far I have got mixed guidance on this.

One theory suggests that backlog items should be estimated in story points in the grooming process i.e., prior to sprint planning. I agree and like this approach as PO & Scrum team get early heads up on size of the items.

On the other hand, there are suggestions that product backlog items should be estimated by the Development Team (using planning poker) only during the first part of Scrum Planning meeting. Based on this DT will decide how much work can be taken as sprint backlog.

Nothing wrong with second approach either. Knowledge is always fresh from the Sprint Planning discussion and that's when team is best equipped to provide the right estimates.

My personal option is to go with a hybrid approach - where early estimation is done in T-shirt sizing during PBL grooming stage, and detailed estimation at story point level is done during sprint planning.

Like to know what others recommend?


07:28 pm July 1, 2015

The only approach I would not recommend is waiting to SP to do estimation.

Do it during refinement(the new name for grooming). The ways you mentioned are both possible options, though I'd question the value of doing T-shirt sizes so close to the time you'll do Planning Poker. Why do both?

Remember that technical estimates can change at any time based on new information.

More there:
http://ScrumCrazy.com/refinement


08:25 pm July 1, 2015

Product Backlog refinement should bring items to a sufficient level of maturity for them to be estimated. If PBI's aren't understood well enough to be estimated by the Development Team then they can't be planned into a Sprint.

If teams wait until Sprint Planning to estimate Product Backlog Items, then there is an appreciable risk of suggested items being rejected from the plan. Estimating during refinement is therefore sensible, because an estimate indicates that an item is in a potentially plannable state (although it might be rejected for other reasons).

Furthermore, by definition each item on a Product Backlog must have an estimate. The backlog cannot be considered well-formed if items remain unestimated.

The Sprint Review provides a final opportunity to prepare the Product Backlog for the next Sprint Planning session. The quality of estimates can be a matter for consideration and revision.


02:05 pm July 2, 2015

> Furthermore, by definition each item on a Product Backlog must have an estimate. The backlog cannot be considered well-formed if items remain unestimated.

I have a different view. I realize that "estimate" is an attribute of a PBI, but IMO, anything that appears to be beyond about 90 days ahead in the PBL does not have to have an explicit estimate. I'm actually totally fine with that field being *blank*/empty in a tool or on a card.

Unfortunately, if we tell people that all PBI's have an estimation, it's a very slippery slope back to BRUF (Big Requirements Up Front), because as soon as we ask the Dev Team to put an estimate on everything, they will ask for more requirement details... and then they willl say that they need to do some minimal design in order to estimate, minimal architecture... etc etc etc -- and while I'm fine with the Dev Team having this view about work in the next 90 days or so, I'm not fine with them doing this work for the PBI's more than about 90 days out. Having said that, if the Dev Team wants to put a SWAG on things beyond 90 days, I'm ok -- but no BRUF allowed. That's waterfall.


02:05 pm July 2, 2015

> Furthermore, by definition each item on a Product Backlog must have an estimate. The backlog cannot be considered well-formed if items remain unestimated.

I have a different view. I realize that "estimate" is an attribute of a PBI, but IMO, anything that appears to be beyond about 90 days ahead in the PBL does not have to have an explicit estimate. I'm actually totally fine with that field being *blank*/empty in a tool or on a card.

Unfortunately, if we tell people that all PBI's have an estimation, it's a very slippery slope back to BRUF (Big Requirements Up Front), because as soon as we ask the Dev Team to put an estimate on everything, they will ask for more requirement details... and then they willl say that they need to do some minimal design in order to estimate, minimal architecture... etc etc etc -- and while I'm fine with the Dev Team having this view about work in the next 90 days or so, I'm not fine with them doing this work for the PBI's more than about 90 days out. Having said that, if the Dev Team wants to put a SWAG on things beyond 90 days, I'm ok -- but no BRUF allowed. That's waterfall.


06:44 am July 4, 2015

I'd be inclined to bite the bullet on those risks, and coach teams to manage granularity and timeliness. The estimates a team gives can be vague, but they ought always to be explicit.

The Guide says: "Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail."

Teams should also be coached to limit the amount of Sprint capacity that they allocate to Product Backlog refinement. The Guide indicates that a maximum of 10% is usually sufficient.

If these practices are observed then (in my view) the risk of BDUF can be mitigated, and the business of delivery promoted.


06:57 am July 4, 2015

> ...the risk of BDUF can be mitigated

Correction: the risk of BRUF can be mitigated.


03:42 am December 24, 2015

Based on your inputs, what would you recommend to a team, that uses Planning Poker cards with "?" as an output of estimation process? Would you treat it as an estimated PBI?


12:21 pm December 30, 2015

If a "?" is played during planning poker, it indicates that further refinement is necessary. It doesn't count as an estimate in itself because the item cannot be planned into a Sprint Backlog as long as complexity and effort remain indeterminate.

Spike investigations may be needed before some items become estimatable.


03:55 pm December 30, 2015

Ian,

I just realized that my question wasn't to reasonable. Usually teams have 1,2,3,5,8,13,21,40,100 cards. If they agree to use "?" instead of 100, then it could be treated like an estimate, couldn't it? I guess it's just about a usefulness of symbol used. "?" is impossible to fill in Jira estimation field :)


03:13 am January 4, 2016

"?" and 100 are not the same.
"?" doesn't mean "big" but "I have no idea"


04:49 am January 4, 2016

Olivier,

my point was it's up to the team how they interpret those symbols. Your interpretation is just one of them.


03:21 pm January 4, 2016

sure, it is just a "classic" interpretation. You can also restrict the symbols with only 3 cards : 1 ; Too F... Big ; No F... Clue
https://pbs.twimg.com/media/BtoVo5NIYAAV0IC.jpg:large


04:47 pm January 4, 2016

The important thing to keep in mind is that, in your example, an estimation value of "?" is larger than an estimation value of 40. It's all relative.

I am uncertain though whether an estimation of "?" can realistically fit within a sprint. If your team believes it can, then your only problem is how to represent the "?" symbol in JIRA, since JIRA won't accept characters as story point values. Why not just use a value of "100" then?

If the team believes that an estimate of "?" is too large to be completed within a sprint, then yes it can be estimated, but it is too large and must be refined further before being accepted by the team.


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

Please note that the first and last name from your Scrum.org 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. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org 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 Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.