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

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

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.

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.

Example:
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

etc.

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.

Conclusion

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.