Velocity is a speed in a specific direction. Velocity is Distance traveled divided by time in a specific direction. This is defined as a Vector. Speed and Direction.
The direction can be a compass heading. A compass heading of an aircraft - 270°. The aircraft can have a 2nd dimension of measure - the compass heading and climbing or descending at a measure of feet per minute.
Speed is Distance traveled over Time. When we are driving we have a speedometer. It says 55 Miles Per Hour. OK, I rarely drive 55 MPH but pretend I was. In one hour (time) I will cover 55 miles. This measure doesn't include the direction. We're driving on the road for the most part, so the direction is predetermined. With speed, we're measuring the distance over that road over time, no matter what the shape of the road is - straight or curved, flat or mountainous.
Velocity in Agile Software Development
Velocity is a term used in agile development. In agile, A velocity is an arbitrary unit of measure, calculated by counting the number of units of work completed in a certain interval, the length of which is determined at the start of the project. The velocity is calculated by counting the number of units of work (Stories or Story Points or any other arbitrary measure) completed in an interval of time (a Sprint), the length of which is determined at the start of the project (some small number of weeks).
These units can be Story Points, Stories, kumquats, or Corgi dogs, and the interval can be a Sprint of 2 or 3 weeks or any other unit. Usually, they are Story Points or Stories, but this is arbitrary.
So 30 Story Points over 2 weeks means 15 Story Points per week - on average - or 5 Story Points per day - on average. This is the average Speed, the instantaneous speed is different, just like the instantaneous speed changes many times a minute. The speed in the agile example is the number of Story Points and the direction is toward the end - direction. But that end we need a unit of measure as well. The Stories and Tasks from the Product Backlog is a direction. Those Stories are definitized from Features in the Prodict Roadmap and Release Plan. That's how we get direction in agile for Velocity.
Velocity = Speed in a Direction. Velocity is a Vector. Speed is a Scalar
Does Velocity effect Cycle Time?
Cycle time is the total time from the beginning to the end of a work process. Cycle time includes process time, where the object under work is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action. For software development, the object is the Story and the development of the Code that implements the Story along with the testing and all the other activities of producing the outcome from the work effort.
If we think of cycle time as the time the Story spends being developed (including all the work to produce working software), over some period of time inside the Sprint, including the entire Sprint. Then we can say...
The cycle time for a Story is the total time from beginning to end for the production of Working Software. Howe long were we working on the Story. This is a unit used in Little's Law as well. The direction this Story is going is toward the end of the Sprint. So the Story has a Velocity. But since the direction is fixed - toward the last day of the Sprint, the passage of time from start to end of the development effort, is it's Seed.
So here's the Question
Does Velocity impact Cycle Time? Answer? YES It Does
Why? Cycle Time and Velocity - when there is a fixed direction (the Sprint) over a fixed duration (2 or 3 weeks where we work) affect the total amount of time the Story is being worked (as we say in our defense software development domain). This time being worked is the Cycle Time for that Story. How fast the work is being done (Speed, as in Velocity with a fixed direction) will impact how long the Story is being worked.
The faster we go the faster the Story will be completed.
So yes,
Velocity does impact the Cycle Time. It impacts that Cycle Time directly. Go fast, finish fast. Finish fast, lower Cycyle Time
After talking this over this morning with a colleague who is responsible for many of the aspects of Agile development in manned and unmanned space flight systems where I work, here's a summary of the notion of Velocity from her point of view - which like mine is from Physics and Math
- Speed is the rate of the production of Story Points by the team over some time - the Sprint
- The direction is the Product Roadmap - where are we going. The Stories and the Features they implement need to have some reason for being there.
So velocity and throughput are directly related. The faster outcomes appear the larger the throughput, measured in a fixed block of time. Since Story Points are a relative (Ordinal) unit of measure expressing an estimate of the effort required to fully implement a product backlog item or any other piece of work, we can assign Story Points to the rate of movement - 20 story points per sprint. This can also be referred to as the capacity for work. Our team can deliver 20 Story Points per Sprint.
And of course each of these variables are random variable impacted by uncertainty, so estimates are needed in the presence of this uncertainty to determine if we are going be delivering what we said we were going to deliver when the Sprint started.
Lastly, when we hear Story Points are not hours, that is also incorrect. We can assign the arbitrary unit of measure - the Story Point - to any Cardinal measure. One program I work assigns ONE Story Point to be 6 hours (an Ideal Day). This is purely arbitrary of course, but once we've exited Story Time where we use Story Points to prioritize the Story, they are converted into Ideal Days to confirm our capacity for work matches the calendar period of performance for that work.
By the Way
There a poster on a cubical wall across from my cubical that says ...
Why is this important? The staff on that side of the passage are contract managers for a Manned Space Flight Vehicle. They are always arguing about the meaning of Affect and Effect and how contractually binding the words they are arguing about, usually some piece of hardware that was built or procured and how that piece of hardware is integrated into a larger piece of hardware - last week the connectivity bolts that attached the spacecraft to the adapter ring on top of the launch vehicle and how it's behaviour will AFFECT the performance of the system after the EFFECT of an explosive separation, which by the way must work 100% of the time or people die.
