Hi Sarah,
Yes, in EIGRP metric, the delay component is cumulative, i.e. it is added along the path to the destination. In your example, the total delay would indeed be 2+2=4 ms and this value would be used in EIGRP metric computations.
Regarding the meaning of the delay, it should represent the overall latency in reaching the particular destination, taking all delays into account (queueing delay, processing delay, propagation delay, serialization delay, etc.). However, in EIGRP, the delay is actually a static parameter set using the interface-level delay command, and does not really represent the delay associated with a particular link. Rather, it is a parameter that - because of its cumulative property - increases with the length of the path itself (i.e. the total delay is positively correlated to the overall path length), thus shorter paths with the same bandwidth are preferred over longer paths with the same bandwidth. Note that having just the bandwidth in the EIGRP metric (as the bandwidth is always taken as the minimum from the advertised and interface bandwidth) without having any cumulative parameter such as delay would make the EIGRP essentially blind and ignorant to the actual path length.
As a matter of fact, the delay parameter is the only parameter that you are allowed to modify in EIGRP to arbitrarily influence its routing decisions. You can obviously modify either the bandwidth or the delay parameters on an interface to make a route through it less or more preferred; however, modifying the bandwidth setting is strongly discouraged because many mechanisms depend on knowing the true bandwidth of an interface - QoS tools, EIGRP's own tendency to allocate up to 50% of the interface bandwidth for its own traffic. Therefore, in EIGRP, if you want to influence the metric of routes learned through an interface, modify its delay setting - never the bandwidth.
Best regards,
Peter
