Correct text for grouped jobs

The hover does not show the count, it is already shown.
Hovering shows the aggregated result - passed or failed
for the grouped jobs.

doc/ci/jobs/index.md

@@ -104,7 +104,7 @@ can find the reason:
 
 In each place, if you hover over the failed job you can see the reason it failed.
 
-![Pipeline detail](img/job_failure_reason_v10_7.png)
+![A pipeline graph showing a failed job and the failure-reason.](img/job_failure_reason_v10_7.png)
 
 You can also see the reason it failed on the Job detail page.
 
@@ -148,11 +148,11 @@ to read.
 You can automatically group similar jobs together. If the job names are formatted in a certain way,
 they are collapsed into a single group in regular pipeline graphs (not the mini graphs).
 
-You can recognize when a pipeline has grouped jobs if you don't see the retry or
-cancel button inside them. Hovering over them shows the number of grouped
-jobs. Select to expand them.
+You can recognize when a pipeline has grouped jobs if you see a number next to a job
+name instead of the retry or cancel buttons. The number indicates the amount of grouped
+jobs. Hovering over them shows you if all jobs have passed or any has failed. Select to expand them.
 
-![Grouped pipelines](img/pipeline_grouped_jobs_v14_2.png)
+![A pipeline graph showing several stages and jobs, including three groups of grouped jobs.](img/pipeline_grouped_jobs_v14_2.png)
 
 To create a group of jobs, in the `.gitlab-ci.yml` file,
 separate each job name with a number and one of the following:
@@ -292,7 +292,7 @@ the [variable is overridden](../variables/index.md#override-a-defined-cicd-varia
 Any variables overridden by using this process are [expanded](../variables/index.md#prevent-cicd-variable-expansion)
 and not [masked](../variables/index.md#mask-a-cicd-variable).
 
-![Manual job variables](img/manual_job_variables_v13_10.png)
+![The run manual job page with fields for specifying CI/CD variables.](img/manual_job_variables_v13_10.png)
 
 ## Delay a job
 
@@ -307,7 +307,7 @@ For example, if you start rolling out new code and:
 - Users experience trouble with the new code, you can stop the timed incremental rollout by canceling the pipeline
   and [rolling](../environments/index.md#retry-or-roll-back-a-deployment) back to the last stable version.
 
-![Pipelines example](img/pipeline_delayed_job_v14_2.png)
+![A pipeline graph with a delayed job.](img/pipeline_delayed_job_v14_2.png)
 
 ## Deployment jobs