Planning Poker Nonsense meets Story Point Bullshit

Planning Poker Nonsense meets Story Point Bullshit

Dogmatists and theorists will forgive me if I take a critical look at two, in my opinion, stupid methodological approaches that I come across and again in my work as an agile coach. The use of Story Points to estimate the scope – … sorry, the complexity – of a requirement, combined with a planning poker.

Both the use of Story Points and the implementation of Planning Poker are not wrong per se. But a meaningful and value-creating application requires framework conditions that are almost never given.

Thesis 1: The use of story points to estimate the scope or complexity of a requirement can only work if everyone involved in the estimation process has the same understanding/feeling about their value.

Thesis 2: A Planning Poker for the „joint“ estimation of the scope/complexity of a requirement can only work if all those involved in the estimation process

  1. know the requirement itself sufficiently well to understand what the customer wants to have realised,
  2. know the object model on which an application is based, if software development is involved, and
  3. have knowledge of the tools – usually the programming language – by means of which the implementation is to take place.

The Story Point itself

If a team compares the scope/complexity of a requirement with a reference – equal to 1 story point – in order to estimate it, this reference must be sufficiently known to all those involved in the estimation process. It is not uncommon for me to come across Scrum teams at customers that are subject to high fluctuation. I question whether all team members are always sufficiently familiar with the (respective) reference with which the requirements to be implemented are compared.

Frequent estimates may give you a sense of the value of the story point in the team where you are earning your daily bread, but how much frequency is needed?

If you are sent out today with a bag of Polish zloty and no conversion table, how long and how many purchases will it take before this foreign currency is as familiar to you as the euro, the US dollar or, in general, the currency in your home country?

Experiment: Ask each team member what the value of a story point is. Do you think you will get answers that give you a feeling that your colleagues all have the same understanding about the value of story points?

The estimation process itself

I am a business consultant and when I was walking past a maize field yesterday, I wondered what turnover and profit the farmer will make from it when it goes to harvest and he sells it.

Quite honest …

I have no idea!

I have far too little knowledge in this area to be able to make even a rough estimate of the effort, costs, turnover and profit. I don’t know how to operate the machines needed to plant and harvest the maize, nor do I have the necessary knowledge of the planting material. This is where I am blank.

Can a florist provide information? After all, plants are her speciality.

Probably not.

What I want to say is that it is not enough to know any programming language and neither the architecture of an application nor the underlying object model.

An expert in front-end development with Angular and JavaScript cannot usually be expected to know the ABAP programming language sufficiently well or to be familiar with the architecture of the monster called SAP.

The following is a list of available SAP modules, each of which is mammoth in size and scope. I wonder whether an SAP ABAP developer who has been working in the area of SAP MM for the past few years is sufficiently familiar with SAP FI to be able to provide a reasonably valid cost estimate for a financial accounting requirement. Even if the same programming language is used for all modules.

  • SAP FI  module for finance
  • SAP CO  for controlling
  • SAP SD or sales and distribution
  • SAP PP for production planning
  • SAP MM for materials management
  • SAP QM for quality management
  • SAP HCM for human resources management
  • SAP BW for Business Warehouse
  • SAP PS for project systems
  • SAP CRM for customer relationship management
  • SAP SRM for supplier relationship management

Note: ABAP, short for „Advanced Business Application Programming“, is a proprietary, multi-paradigm programming language based on COBOL.

Statement: If you don’t have a reasonable amount of knowledge to make an estimate, you shouldn’t do it.

The Planing Poker

Agile is not project management. Agile is used for agile product development. A product, or a solution, is often a complex construct of different applications and systems.

For the development of an eShop through which industrial cables are sold, the following systems are part of the Solution eShop:

    • SAP CRM (Customer Relationship Management)
    • SAP PP (Production Planning)
    • SAP SD (Sales and Distribution)
    • SAP FI (Financial Accounting)
    • a Product Information System, PIM for short, from which the product descriptions are delivered to a web front end in text and images
    • AEM – Adobe Experience Manager -, a content management system
    • Angular und Javascript
    • Angular and Javascript


If an Agile Release Train (ART) consists of several Scrum teams, in which experts from different systems (see example) do their work, then it is extremely unlikely that an Angular expert has the necessary knowledge to be able to estimate the part of a customer requirement that contains components of SAP FI. See also my comments on the estimation process.

After a deeper look at thesis 2, we need to ask who in a feature team ever has the comprehensive knowledge to provide a valid effort estimation.

If planning poker is to take place, then only among those who are qualified to do so. Please do not „force“ people to give estimates that have no sound basis in terms of the knowledge required to do so.


Even more important than the detailed application of a method is the use of common sense. Even if the majority may use certain methods, you should always critically scrutinise the sense and purpose of their use in your own context.

In the end, results are what count. If the degree of target achievement, i.e. the ratio between plan and actual implementation, between commitment and completion, is usually (far) below 50 %, it probably won’t work.

If you want to specifically improve your degree of target achievement and thus the success of your project, then

Keine Kommentare

Share This Story, Choose Your Platform!

Über den Autor:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Bitte füllen Sie dieses Feld aus.
Bitte füllen Sie dieses Feld aus.
Bitte gib eine gültige E-Mail-Adresse ein.
Sie müssen den Bedingungen zustimmen, um fortzufahren.