PBI Estimation

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.

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.

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.

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.

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.

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.

> 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?

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…

@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

@ 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.

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)

@Luis :
+1


T

@ 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.

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.

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?