You Only Live Agile!

Yola & Co. and the pokering PO…

007 - Yola & Co and the pokering PO (1000x456)

Once in a while I encounter teams that do poker planning and that includes the Product Owner or even Scrum Master. But that is not how it supposed to be!

Poker planning is a method to plan the amount of work to be done before a team implements a small functional increment or Product Backlog Item (PBI).  And who is implementing this PBI?….Yes, indeed, the development team. Now this is where Scrum becomes a bit fuzzy. There are two entities called team within Scrum, the Scrum team and the Development team. Sometimes both called team. So I do understand where the confusion comes from, but we have to keep in mind what the purpose of poker planning is. It is for estimating the work to be done to implement a PBI that is ready to be picked up in the sprint. The Product owner is not doing the implementation of a PBI.

The Product Owner is the one that is accountable for the ROI, thus creating the most valuable PBI’s from the backlog for the next sprint. So he/she will be very busy getting enough information to get the most important PBI’s ready, especially with high performance teams this is a hell of a job to do (but a very rewarding one). Besides getting things ready, he/she will be very busy doing stakeholder management to determine the PBI’s with the highest value. Thus he/she will not take part in actually implementing it. This is why only the development team should take part in the poker planning.

The development team is putting all their effort in the implementation of the PBI to get it done. They have their meat in the product so to speak. They use the poker planning to estimate the relative size of a PBI with respect to previous PBI’s they estimated. It is very important to let them do the estimation of the PBI’s because it will influence their velocity. We don’t want to interfere with this process because it’ll influence the rhythm, or one piece continuous flow of the team. What we’ll get back if we back off will be a predictable team, and is that not what we like to have most of all, predictability?


Yola & Co. are Spotifying…(including checklist).


Yola & Co got tickets for Agile Coach Camp Nederland 2016…


  1. Wouter

    You’re absolutely right. It becomes fuzzy when a PO is mainly involved as a team member and his/her skills are not spreaded across the team.

    • Yola

      Hi Wouter,

      You are right that it becomes fuzzy when a PO is also a team member. But in those situations I start questioning the PO’s role in the first place. Most of the time he is merely a translator of the PBI’s into more technical PBI’s that the team can understand. The true PO will be found somewhere else in the company. What this pseudo PO is doing is basically some sort of pre-refinement.

      So in this situation I would do the following:
      1. Find the true PO that has the mandate and the budget to act as a PO for the team.
      2. Start refining with the whole development team and PO so business and IT learn to cooperate and understand each other.
      3. Coach management in properly doing Scrum. They see dedicated PO’s and Scrum Masters as overhead because they add the traditional project manager to the project. Thus they create the problems themselves 🙂

      Those three steps are just for starters of course. We try to create high performance Scrum teams by continuously improving ourselves. I’ve been in situations with high performance Scrum teams that were able to outpace a PO-team that was 30% bigger. Believe me, in this situation the PO couldn’t be a part of the development team at all!

  2. Wouter

    I think there is a situation that doesn’t fit in this reasoning. In several organisations, PO is considered as a role. In many cases, his/her “teamskill” is one that is not spreaded across the team. Let’s say his teamskill is Customer Journey Expert and he needs to do actual work to complete a PBI. If he doesn’t play poker during the refinement, the CJE tasks are not estimated.

    • Koen


      As Yola said; you have the wrong PO. A POs job is to get a backlog that is implementable by the team (“Ready”). If he does that job well, he doesn’t have any time to do work to get the PBIs “Done”.

      Having a PO be part of the Development team is a Scrum Smell. It doesn’t work. It shouldn’t happen.

  3. Paul

    Planning Poker should be a discussion purely around the complexity of a user story; what is exactly meant, against what acceptance criteria etc. If a PO feels the tendency to influence this discussion in his/her direction, this should be corrected by the rest of the team (where a PO is part of) or an Agile Coach.

  4. Linda van der Pal

    I’ve actually seen it work in several projects, where the PO was involved in pokering. BUT when their estimate was different from the team it was ignored. The added value of the PO pokering was that they get a feeling for the complexity of issues.

    • Yola

      Hi Linda, thank you for your comment. Of course there are situations in which the pokering PO is not immediatelly an impediment for the team. Fact remains though, that the PO is actually influencing the estimation of the team and therefore putting pressure on the team. A better solution for the PO to get a feeling on the complexity is rather in the communication, the first value of the Agile Manifesto; individuals and interaction…. The poker session is for the development team to create a forecast and while they have meat in the product, the PO is merely interested in predictability. This predictability is being influenced by the PO’s own pokering. For me, I only let people poker on the work they are going to do, those who have meat in the product…

Comments are closed.

Powered by WordPress & Theme by Anders Norén

WordPress Appliance - Powered by TurnKey Linux