From my understanding, planning poker involves the development team or the executors of the project and the project manager or the project owner. I recently had a debate with our project manager on this issue about whether or not to include a client in this activity.

Here are the arguments for both sides:


I advocated against this because i feel if a client is in the room there is the possibility of changing our estimates and making them more optimistic than they are because the client is in the room.


On the other hand, if the client is in the room they could provide and clear up requirements and let them understand the process and the value it could provide.

My Question

Therefore, my question is the following. In the best interests of estimation accuracy (i know it is almost impossible to be accurate), which it be best to include a client on this activity or preclude them?

edit by said PM: Should be noted that in this case the client is both the project owner and sponsor.

9 Answers 9


Regardless the methodology used for estimates, I wouldn't suggest to have the client involved in the process of estimations. Some further reasons, besides the ones you mentioned:

  • Clear up requirements: Estimation meetings are long enough only discussing about estimates. Discussing the cleanliness of a requirement would only add another level of complexity in the meeting. I'd say that's better to take note of the requirements that aren't clear and discuss in an appropriate meeting with the client.

  • Time wasted: No one likes to waste time. The client is likely to get upset with some discussions going back and forth about things that are 'obvious' from a business perspective.

  • Estimations biased: Having a senior client in the room may compromise the estimates for several reasons, like shyness of junior developers raising points they may not be sure how relevant are. Besides, who'd say 'padding' having the client in the meeting room?

  • Point of view: The client sees the final product, and you guys are thinking of the whole project. How can both things be discussed, and what value would it add? I've never been invited to discuss about the structure of the car I'm intended to buy... but I clearly know the characteristics I want to have in the car.

There are plenty of other reasons, and I'm looking forward to see other peer's opinions.



The term client suggests a buyer-seller relationship. If there is a contractual relationship with a monetary transaction, then the client has zero business in the estimation process. The client would wisely conduct its own estimation process to prepare for negotiations.

To include them is like playing poker with your cards faced up.


As others have said - No, the client should not be in the room or involved in the estimation or planning process. Those are internal processes that should be done by those actually 'doing' the work, and who have the experience and expertise to make those estimates. Regardless of the relationship between the team and the client, the team will feel some sort of pressure to estimate on the optimistic side if the client is in the room. If the client is actually 'involved' in the discussion it will be even worse, as they will undoubtably attempt to skew the estimates lower.

Having said that, this doesn't mean the client can't or shouldn't have a say in the final decision. This is known as 'value engineering' in other domains. Once the planning poker is finished and the estimates and total duration are known for the current requirements, then you can (and should) go back to the client and show them the results. Let them see what can/can't be done, and how long it will take. At that point, they then have the option of modifying the requirements if they need something faster or different.

This is a routine process in many projects, especially construction. Once the estimate and schedule are completed from the original drawings/blueprints, it's not uncommon for the Owner to say "is there any way for us to cut the time or budget?" At that point the contractor can either go back and look at options in-house (substituting materials, new methods, etc.) and revising the estimate, or include the Owner in discussing options and things to either modify or eliminate to reach their goals.

The key here though is that you have to start from a base estimate where you're sure that if the client syas 'go ahead', you can complete as promised. And the only way to get there is to have those doing the work, and only those doing the work doing the estimates. For me, this has also meant excluding our sales or account reps.


If the team is mature enough to not be influenced by the presence of the client in the room, sure, why not.

You overstate the value of the client in the room for the sake of better defining requirements. Estimates are guesses and you're not going to get a lot of value out of being slightly better at guessing.


I would say that if you have a Product Owner that is the true representative of the business, then you would not need the "client" in the room. However, this would be the pure definition of a product owner, one that is dedicated to the prioritization and understanding of the product (read: SME). This person should have enough information to answer any question that the team has for them and if not, how would one be able to truly estimate the size.

The concern about involving the "client" (again i put these in quotes, because the product owner can be viewed as the client) would be wasting time during the estimation process by thinking about additional ideas. If this is the case, I'd skip the story and move on to the next one that can be fully defined :)


From my understanding, planning poker involves the development team or the executors of the project and the project manager or the project owner.

It depends on what exactly you mean by planning. If you're in the requirements gathering phase where you're meeting with the client to document what they want, then obviously you'll want the client to be there. This should of course have nothing to do with estimates as no one technical has actually had any significant time to actually sit down and calculate real estimates (not "gut-feeling" estimates)

If the development team is meeting with the PM to determine estimates or how to proceed in turning the functional requirements into working code, then the client shouldn't be involved in this. This activity is technical in nature and is the job of the development team.

  • Good point with division meeting into elaborating/gathering (1) and estimating (2) phase. I would add that in the second phase client can be available to the team, so when during estimating team needs clarifications, they can ask client/customer directly. May 12, 2012 at 9:08
  • Still, I would think there would be some part of the estimation phase where the dev's go into a state of quiet contemplation so they can actually go through each feature and calculate how long it will take. It's hard to do that with a bunch of nontechnicals asking you redundant questions while you're trying to think :) If there are areas where clarification is needed, then I think an estimation meeting with the client would then be in order :)
    – jmort253
    May 12, 2012 at 9:22
  • Maybe I was not clear enough - I agree with you that there must be a moment of 'quiet contemplation' as you write. What I meant was that it could be broken for a while IF there is will from the team to do so. For example if team estimates a task and gives 8, but knows it can be 5 if ie. textbox is generic then they can have option to ask customer/client that particular question. May 12, 2012 at 9:42

For an inexperienced PM (which I was that time), having the client in the room was not good because we ended scoring exactly what the client wanted us to score. So, when we said "5", they said "2", we always stopped and "2". In the long term, we had a very poor scoring.

But maybe, for an experienced PM it could be a chance...


You probably should not have the client in the room, Tiago and David have given some good reasons for this.

But you do need to have user/client interests represented in some way in order to make sure assumptions around the estimates are reasonable, contractual requirements are met, etc. Ideally whoever the representative(s) have a clear understanding of the business case as well as technical requirements. Their role wouldn't be to veto estimates or massage them into something palatable ("The client will not like that" syndrome), but to help raise flags, start discussions to find solutions, and proactively come up with answers to likely client questions on the estimate.


It sounds like the general consensus is that the client should not be in the planning meeting. I really don't understand this - surely in order to have a good planning session you need to understand clearly what is needed. For this wouldn't the client be the perfect person to clarify the stories?

I appreciate that this is supposed to be the role of the Product Owner, but given that there is a client (singular rather than plural) suggests that the project is to deliver something bespoke for a single customer. Having them available during the planning to answer any queries and assist the team getting to the right solution sounds to me like a better match than the Product Owner, who will always be relaying a second hand perspective.

Maybe I have the wrong end of the stick, but I cannot really see any downside to having the client in the room as long as they are made aware of the process you are following so know what to expect. Ultimately the story point estimates are just estimates and are used to help scheduling rather than directly determining the contract end date so I would not be too concerned with the presence of a client affecting the estimates.

If the estimates are wildly different between the client and team, and after discussion you are unable to come closer, I would side with the team since they are the people who need to deliver.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.