v is for...

The Agile Values were formalized by a group of software development pundits who gathered in Snowbird, Utah in February, 2001 to attempt to collectively grok what all of them recognized as an emergent trend in their various practices. What they emerged with was a new name for what they did–Agile–and an Agile Manifesto that consisted of Values and Principles, and an organization that would eventually be formalized as The Agile Alliance.

The Values (taken directly from the Agile Manifesto) are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Etymology

The Agile Values were originally stated in the Agile Manifesto.

The rate at which an agile team completes work, used not to measure progress per se, but to accurately estimate the team’s capacity for future iterations and guide the team and product owner in planning upcoming iterations.
In the first iteration, a team has no velocity; they take a flying guess at how much work they will complete. But from iteration two onward, velocity is derived from the amount of work the team completed in the previous iteration or iterations.
Different teams use different units of measure for estimating work and determining velocity, some of the most common being: story points (Scrum), craft units (XP), ideal days or hours. The team may determine its velocity by averaging the amount of work completed to date over the number of iterations completed (work/time), or simply by taking the amount of work completed in the previous iteration and carrying it forward.
The data used to determine a team’s velocity may be documented on the project Burn Down and Burn Up charts.

Background of the Term

Originally, advocates of Extreme Programming estimated in terms of Load Factor, which was the inverse of velocity, being time/work. “We think velocity is the simpler term, so Load Factor is falling out of use,” Robert C. Martin wrote in 2000. Kent Beck said much the same in his 2000 book, Planning Extreme Programming: “We used to use load factor a lot in planning, but since then we have learned that it’s easier to just use velocity.”

Further Learning

An Agile Learning Labs blog post: https://agilelearninglabs.com/2009/01/track-velocity-not-time-spent-on-tasks/