Add explanation for eagerScalingStrategy

content/docs/2.15/concepts/scaling-jobs.md

@@ -159,7 +159,7 @@ scalingStrategy:
   strategy: "default"                 # Optional. Default: default. Which Scaling Strategy to use. 
 ```
 
-Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.
+Select a Scaling Strategy. Possible values are `default`, `custom`, `accurate`, or `eager`. The default value is `default`.
 
 > 💡 **NOTE:**
 >
@@ -230,6 +230,46 @@ if (maxScale + runningJobCount) > maxReplicaCount {
 ```
 For more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).
 
+**eager**
+When adopting the **default** strategy, you are likely to come into a subtle case where messages need to be consumed by spawning jobs but remain in the queue, even when there are available slots between `runningJobCount` and `maxReplicaCount`. The **eager** strategy comes to the rescue. It addresses this issue by utilizing all available slots up to the maxReplicaCount, ensuring that waiting messages are processed as quickly as possible.
+
+For example, let's assume we configure a ScaledJob in a cluster as below:
+```yaml
+  ###
+  # A job that runs for a minimum of 3 hours.
+  ###
+  pollingInterval: 10 # Optional. Default: 30 seconds
+  maxReplicaCount: 10 # Optional. Default: 100
+  triggers:
+    - type: rabbitmq
+      metadata:
+        queueName: woker_queue
+        hostFromEnv: RABBITMQ_URL
+        mode: QueueLength
+        value: "1"
+```
+We send 3 messages to the Rabbitmq and wait longer enough than the `pollingInterval`, then send another 3.
+
+With the `default` scaling strategy, we are supposed to see the metrics changes in the following table:
+
+|             | initial | incoming 3 messages | after poll | incoming 3 messages | after poll |
+|-------------|---------|---------------------|------------|---------------------|------------|
+| queueLength | 0       | 3                   | 3          | 6                   | 6          |
+| runningJobs | 0       | 0                   | 3          | 3                   | 3          |
+
+
+If we switch to `eager`, the result becomes: 
+
+|             | initial | incoming 3 messages | after poll | incoming 3 messages | after poll |
+|-------------|---------|---------------------|------------|---------------------|------------|
+| queueLength | 0       | 3                   | 3          | 6                   | 6          |
+| runningJobs | 0       | 0                   | 3          | 3                   | 6          |
+
+We can identify the difference in their final states.
+
+
+You may also refer to [this original issue](https://github.com/kedacore/keda/issues/5114) for more information.
+
 ---
 
 ```yaml