Add new delay cause and minor editing in progress

Author: Steve Danielson

docs/managed-devops-pools/configure-scaling.md

@@ -888,12 +888,13 @@ If you don't know your usage patterns and want to rely on automatic forecasting
 
 ## Lifecycle of agents and potential delays in allocation
 
-When using a Stateless scheme, ready agents require the Azure DevOps Task Agent to both be installed and set up in order to run an Azure DevOps pipeline. When provisioning new agents, Managed DevOps Pools attempts to download the latest [Azure DevOps agent](https://github.com/microsoft/azure-pipelines-agent/releases) in order to have it already downloaded on buffered agents. Startup, connection, and beginning the job can take anywhere from 10 seconds to a minute depending on the pool's SKU speed, image used, and networking load. Additionally, certain settings in a pipeline job can cause a redownload and running of a different agent, and regressions and rollbacks of the agent can also cause a redownload of the agent. Ready agents will always have a potential delay, as Managed DevOps Pools uses this agent in an "ephemeral" manner, meaning we startup and run the task agent one time per job.
+When using a [Stateless](#stateless-pools) scheme, standby agents in a [ready](./view-agents.md#status) require the Azure Pipelines agent to be installed and configured before transitioning to the [allocated](./view-agents.md#status) state and running a pipeline. When provisioning new agents, Managed DevOps Pools attempts to download the latest [Azure Pipelines agent](https://github.com/microsoft/azure-pipelines-agent/releases) in order to have it already downloaded on standby agents before they transition into ready status. Startup, connection, and beginning the job can take anywhere from 10 seconds to a minute depending on the pool's SKU speed, image used, and networking load. Additionally, certain settings in a pipeline job can cause a redownload and running of a different agent, and regressions and rollbacks of the agent can also cause a redownload of the agent. [Ready agents](./view-agents.md#status) will always have a potential delay, as Managed DevOps Pools uses this agent in an "ephemeral" manner, meaning we startup and run the task agent one time per job.
 
 If you are seeing delays in ready agents picking up jobs from Azure DevOps, the following are important to consider:
 
-* Do you have ready agents? - The most common issue is a misunderstanding of when agents should be preprovisioned. When the amount of jobs queued is greater than the buffer on a pool, or jobs are queued when the buffer is set to be empty, then machines must be spun up from scratch.
-* Are you using the buffer with multiple images properly? - If you are not specifying which image to use in your pipeline using the ImageOverride demand, jobs will be targeting the first image. This means, depending on your Scaling settings, you might not have as many agents available as you'd expect as some are allocated to other images.
+* Do you have ready agents? - The most common issue is a misunderstanding of when agents should be preprovisioned. When the amount of jobs queued is greater than the standy agent count on a pool, or jobs are queued outside of the pre-provisioning schedule, when the standy agent count is set to be empty, then machines must be spun up from scratch.
+* Are you configuring standby agents with multiple images properly? - If you are not specifying which image to use in your pipeline using the [ImageOverride](./demands.md#imageoverride) demand, jobs will be targeting the first image. This means, depending on your Scaling settings, you might not have as many agents available as you'd expect as some are allocated to other images.
+* Are you using the [ImageVersionOverride](./demands.md#imageversionoverride) in your pipelines? - When you use `ImageVersionOverride` to specify a different image version than what's configured in your [pool settings](./configure-images.md), each agent is started on demand using the specified image version. Standby agents are provisioned using the image versions specified in your [pool's configuration](./configure-images.md), so if you use `ImageVersionOverride`, any standby agents won't match that version and a fresh agent is started.
 * Are Proxy/VNet/Firewall settings slowing down your pool? - Potential slowness from any network setting will result in agents taking longer to start the agent and connect it to Azure DevOps.
 * Are you overriding the agent version? - By default, Managed DevOps pools will run on the most recent Azure DevOps task agent version. Settings in the Pipeline yaml (such as the "Agent.Version" demand) and Azure DevOps org can force pipelines to use older versions of the task agent, requiring a redownload once a machine has been allocated.