Skip to main content

PBI Estimation

Last post 03:54 am October 8, 2016 by Vivek Puranik
15 replies
04:31 pm September 2, 2016

SBI is estimated (relative estimation) by the development team in sprint planning meeting. But I would like to know what method is being followed in different organization or by SMs about PBI estimation?

WHO/ HOW/ WHEN PBI is estimated? ( I am expecting practice followed rather than theory.)

Thanks


06:14 pm September 2, 2016

To conduct relative estimation we use the technique invented by James Grenning and popularized by Mike Cohn called Planning Poker. It works really well. Just google "Agile Estimating and Planning: Planning Poker - Mike Cohn " and you'll find a lot of information about it (articles, youtube videos and so on).
The Development Team is responsible for all estimates and we do it during Sprint planning meeting.


09:30 pm September 2, 2016

Whatever you said is perfect but it is about SBI - sprint backlog item.
My question is related to PBI estimation. Who/When/How the PBI estimated? Because that is the basis of CFD and even for forecasting using velocity.


10:34 pm September 2, 2016

Oops. Sorry, I was not attentive.
We (the Development Team) do our estimation during Product Backlog refinement. The Product Owner can add PBIs to the product backlog whenever he / she likes and they wait for the next refinement meeting to be estimated.
To conduct relative estimation of PBIs we use Planning Poker as well. Some teams adopt more abstract classifiers, such as T-shirt sizes but we don't use this extra layer of abstraction.


04:19 pm September 3, 2016

Hi Atul and Oleksii,

first of all, no offense but there's no really such a thing called SBI (Sprint Backlog Item) but I understand that you are making reference to the PBIs forecasted to be delivered at the end of a particular Sprint.

On the other hand, Scrum does not prescribe any particular way of estimating but Planning Poker is a technique widespread. So therefore you can use Planning Poker to estimate your PBIs. And that partially solved your how question. You also ask about who and when. Well, it's quite similar to the first part of a Sprint Planning Meeting. The Scrum Master facilitates a meeting in which the PO and the Development Team refines the PB, that means the PO and Development Team change opinions about the product adding information, splitting, estimating or even discarding PBIs. This meeting is usually called: Product Backlog Refinement Meeting or Refinement Meeting for short. Finally, the when. It's not set by the Scrum Guide when you should perform these meetings but as a rule of thumb they don't have to consume more of 10% of the time of your Sprint, that is 1 day for a 2 week Sprint. Some advices from my experience for these meetings:

Do not set these meetings at the beginning or the end of the Sprint. At the beginning they do not have much sense and at the end the DT is usually totally focused on finishing things.
Observe how they respond to a large refinement meeting and how they respond to short meetings. Sometimes a great conversation is taking place and some time the meeting kill the energy of the attendees. But I've generally experienced that 1-4 hour meetings work well.
And finally Mike Cohn says that this meeting should take advantage of a previous interruption, that is, just after the Daily Scrum is a great moment to have a refinement session. Otherwise the DT has to stop doing whatever they were doing, losing focus.


04:23 pm September 6, 2016

Do not set these meetings at the beginning or the end of the Sprint. At the beginning they do not have much sense and at the end the DT is usually totally focused on finishing things.



This is an excellent observation, Luis.

Regarding the "who" question, it should be the entire Development Team establishing the relative estimate for a PBI.

I actually worked with an Agile Coach who recommended that the PO also provide an estimate. Granted, the PO often had no point of reference for sizing the story, and would likely provide estimates outside of the Development Team's range.

The argument was that involving the PO not only helped to make the estimation process transparent to the PO, but also aided story understanding between the PO and the Development Team. Over time, the PO would gain insight and experience into what the Development Team viewed as a "5" or a "13", etc.

It was quite an interesting and unique perspective.


04:53 pm September 6, 2016

Thank you @Timothy.

I've also heard about this PO estimating thing. And I've also read about some sessions in which not the entire DT is present because the sessions is just for some clarifications and not for estimating.


11:42 pm September 16, 2016

> Over time, the PO would gain insight and experience into what the
> Development Team viewed as a "5" or a "13", etc.

Insight and experience is one thing. A PO can play along side and gain that. But was the PO franchised with a vote that counted? If so, why did he or she have skin in the Development Team's estimation game?


02:57 pm September 19, 2016

Insight and experience is one thing. A PO can play along side and gain that. But was the PO franchised with a vote that counted? If so, why did he or she have skin in the Development Team's estimation game?



This was an interesting perspective, and again showed me that there are always different strategies available to approach the things that we do.

I understand the possible risks of a PO presence and input into the estimation process. In my experience, Development Team members consist of developers, business analysts, and testers, as well as operations staff and database analysts in a more Dev Ops team approach. When estimating, it is rare for team members with varying skill sets to be able to really identify with the effort needed in areas outside of their expertise (i.e. - B/A --> Dev, Dev --> testing, etc). This comes with experience of course.

In my mind, Scrum sets the precedent of cross-functional roles within a Development Team gaining insight into efforts that they have little experience or knowledge of.

So while the Development Team as a whole learns about what is needed to deliver the end product according to DoD, and begins estimating as a team/unit, the question is "why involve the PO in this estimation process"?

Why indeed? And a corollary question just might be "Why not?" I do not have a definitive answer to either.

Below is a brief article from the Agile Coach on the subject. I may have been mistaken by calling it a recommendation, but I do see the potential benefits of such an approach, provided the PO and Development Team are willing to try it.

http://www.vitalitychicago.com/blog/should-you-include-or-exclude-agile…


04:37 pm September 19, 2016

@Atul:

Who: Development Team. No PO by all means. (Only Jaffa (beginners/show-off theor guys) SMs/Theoretical Agile PMs who work as SMs will allow PO to estimate)
When: During Backlog refinement (preferably during middle of the sprint).
How: Tons of methods (one of them is T-Shirt Sizing)

Happily, I hate writing tons of theory in every other post.

T


07:07 pm September 19, 2016

@ T Srinivasulu


No PO by all means. (Only Jaffa (beginners/show-off theor guys) SMs/Theoretical Agile PMs who work as SMs will allow PO to estimate)



I would be interested in your reasons why the Product Owner definitely should not participate in estimation.

Hopefully you have taken a couple minutes to read the blog article I posted from an Agile Coach on the potential benefits of including the PO in estimating. Best to make statements when you have digested all of the available information at hand, yes?

I personally do not have a strong preference one way or another on PO involvement in estimation. I do feel I have given the subject a good amount of thought, though. And I can assure you that I am not a Jaffa (beginner) or theoretical (show-off?) SM.

What I can say with a high degree of certainty is that statements like yours can be quite destructive. Try not to be so openly dismissive of contrarian viewpoints, and try not to lump individuals into such belittling categories. Listening, even when the thoughts and opinions of others may run completely counter to your beliefs, is a critical Scrum Master skill.

Here's hoping you are far more open-minded in your actual SM practice.


09:16 pm September 19, 2016

Quoating the Scrum guide:


The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.



From this quote I understand is only the DT who has to really estimate. The estimation techniques comes from the Delphi method in which the experts do the forecast. So consequently I think only the people who collaborate to the Increment are the people who should estimate. What value can add the estimation of the PO?

I have read the article you have linked TImothy, the author starts saying that is a good point to say that only who participates in the Increment estimates (better estimates and gaining in ownership). What's the purpose to educate the PO on sizing PBIs? I think it's easier that the PO asks if he/she does not understand a particular estimate (both when it's low or high)


07:35 am September 20, 2016

@Luis :
+1


T


08:46 pm September 21, 2016

@ Luis

What's the purpose to educate the PO on sizing PBIs? I think it's easier that the PO asks if he/she does not understand a particular estimate (both when it's low or high)



If you read carefully, you may have actually answered your own question.

Let me be clear that I raised similar objections around PO involvement in estimation. It does contradict the Scrum Guide, and I am a strong advocate of the Development Team owning their estimates, since they are the ones performing the work.

But you present an interesting situation. You acknowledge that the team may need to address PO questions related to understanding team estimations, yet you also ask what the purpose is to educate the PO about estimation?

Perhaps the value in involving the PO in the estimation process is around education and aiding the PO's understanding of how the team sizes PBI's?

I understand that the PO "could" gain the same level of insight by observing the estimation process and not participating, but it is my experience with PO's that they are very busy individuals, and likely will not make time to just be a fly on the wall while the team sizes the stories. Active participation may be the key to educating the PO on how the team estimates.

Again, I'm not advocating PO involvement in estimation, but the idea was presented to me, and I do see the potential benefits of such a strategy.


09:05 am September 23, 2016

I'm still not convinced. I understand that the best way to learn is really experiencing so it would be better that the PO particpates than he/she does not ... But that learning should have a purpose and implies some exigencies. The PO does not have to know the detail of implementation, indeed, in many cases could not understand much of the details that are expressed when an estimate is debated. So he might be just throwing cards...

I have nothing against that PO knows how to estimate and how it works, or he to be present (in fact it would be possitive to have him/her near to answer PBI questions) but to get that, the Scrum Master can simply teach the PO how these estimates work (relative sizing I mean) but I do not see valuable to have a business person trying to guess a value without know the details.


03:54 am October 8, 2016

I think PO can ATTEND the estimation exercise, but may not PARTICIPATE in it... Or may, PO can participate only to provide clarifications and answer any questions.
Does PO have to provide sign-off or agreement to the estimates done by team?
Afterall, DT is the one who will converting PBIs in product increments, so better leave them with their estimates and no need to get any authorization\sign-off from PO. Any thoughts?


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.