Estimating product backlog items
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?
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
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.
> 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.
> 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.
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.
> ...the risk of BDUF can be mitigated
Correction: the risk of BRUF can be mitigated.
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?
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.
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 :)
"?" and 100 are not the same.
"?" doesn't mean "big" but "I have no idea"
Olivier,
my point was it's up to the team how they interpret those symbols. Your interpretation is just one of them.
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
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.