{"id":5003367,"date":"2015-12-17T00:20:42","date_gmt":"2015-12-17T08:20:42","guid":{"rendered":"https:\/\/aadev22.local\/?post_type=aa_glossary&#038;p=5003367"},"modified":"2022-08-30T12:17:28","modified_gmt":"2022-08-30T19:17:28","slug":"velocity","status":"publish","type":"aa_glossary","link":"https:\/\/agilealliance.org\/glossary\/velocity\/","title":{"rendered":"Velocity"},"content":{"rendered":"<p>At the end of each iteration, the team adds up effort\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/estimation\/\">estimates<\/a>\u00a0associated with\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/user-stories\/\">user stories<\/a>\u00a0that were\u00a0<a href=\"http:\/\/guide.agilealliance.org\/guide\/sashimi.html\">completed<\/a>\u00a0during that iteration. This total is called velocity.<\/p>\n<p>Knowing velocity, the team can compute (or revise) an estimate of how long the project will take to complete, based on the estimates associated with remaining user stories and assuming that velocity over the remaining iterations will remain approximately the same. This is generally an accurate prediction, even though rarely a precise one.<\/p>\n<h2>Expected Benefits<\/h2>\n<p>\u201cWorked example:\u201d an agile team has started work on an iteration, planning to complete stories A and B, estimated at 2 points each, and story C, estimated at 3 points. At the end of the iteration, stories A and B are 100% complete but C is only 80% complete.<\/p>\n<p>Agile teams generally acknowledge only two levels of completion, 0% done or 100% done. Therefore, C is not counted toward velocity, and velocity as of that iteration is 4 points.<\/p>\n<p>Suppose the user stories remaining represent a total of 40 points; the team\u2019s forecast of the remaining effort for the project is then 10 iterations.<\/p>\n<p>Velocity is also used to limit the amount of work taken on in further iterations. In our example, the team would be well advised to plan for only 4 points worth of stories in the next iteration. This doesn\u2019t necessarily mean it will complete only that much; in fact, completing story C in the next iteration might mean that the team\u2019s velocity will, on the contrary, be much higher.<\/p>\n<p>Agile teams consider both kinds of events a warning sign: failing to bring a story to completion \u201cor\u201d seeing their velocity \u201csee-sawing\u201d. The expected response is to seek a finer-grained decomposition of stories.<\/p>\n<p>Velocity thus serves in a few different ways as a regulation mechanism.<\/p>\n<h2>Common Pitfalls<\/h2>\n<p>The above definition of velocity has a few further consequences:<\/p>\n<ul>\n<li>velocity is a \u201cmeasurement\u201d, made after the fact; though it can help plan ahead, it is not itself a budget or a forecast, and phrases such as \u201csetting the velocity\u201d reveal a basic misunderstanding<\/li>\n<li>velocity is defined with respect to units of value (user stories) rather than with respect to units of effort (tasks)<\/li>\n<li>only the aggregate velocity of the team matters, and the phrase \u201cindividual velocity\u201d is meaningless; a team is a mechanism intended to yield more than the sum of its individual parts<\/li>\n<li>there is no meaningful comparison of velocity \u201cbetween\u201d different teams, since such teams may have different approaches to estimation<\/li>\n<li>in order that velocity provides forecasts of the project\u2019s end date, it is necessary that all of the <a href=\"https:\/\/agilealliance.org\/glossary\/user-stories\/\">user stories<\/a>\u00a0making up the project be estimated in a consistent manner; this can be achieved in one of two main ways:<\/li>\n<li>estimate the entire set of user stories before the project starts, or early on, such as in the first few iterations;<\/li>\n<li>use\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/relative-estimation\/\">relative estimation<\/a>\u00a0to ensure that estimates made later on are consistent with the ones made at the start of the project<\/li>\n<\/ul>\n<h2>Origins<\/h2>\n<p>\u201cVelocity\u201d may be one of the best illustrations that concepts in Agile discourse do not appear full-blown but are worked out over a period of time. Early texts (such as\u00a0<a href=\"http:\/\/www.amazon.fr\/dp\/0201710919\">\u201cPlanning Extreme Programming\u201d<\/a>) were generally favorable to measuring \u201cindividual velocity\u201d, a practice that fell into disrepute over the next few years. \u201c<a href=\"https:\/\/agilealliance.org\/glossary\/points-estimates-in\/\">Story points<\/a>\u201d became the most widespread unit of estimation, displacing \u201cideal weeks\u201d. These changes, hashed out over mailing lists, Usenet, and other fora, are sometimes difficult to pinpoint in time, and only clear in retrospect.<\/p>\n<ul>\n<li>2000: the term \u201cvelocity\u201d is a relatively late addition to<a href=\"https:\/\/agilealliance.org\/glossary\/xp\/\">\u00a0Extreme Programming<\/a>,\u00a0<a href=\"http:\/\/tech.groups.yahoo.com\/group\/extremeprogramming\/message\/365\">replacing<\/a>\u00a0a previous notion of \u201cload factor\u201d deemed overly\u00a0<a href=\"http:\/\/c2.com\/cgi\/wiki?VelocityVsLoadFactor\">complex<\/a><\/li>\n<li>2002: the Scrum community\u00a0<a href=\"http:\/\/tech.groups.yahoo.com\/group\/scrumdevelopment\/message\/617\">picks up<\/a>\u00a0the practice of measuring \u201cvelocity\u201d<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Velocity is the total effort estimates associated with user stories that were completed during an iteration. <\/p>\n","protected":false},"author":8027401,"featured_media":8067461,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","categories":[908],"tags":[],"class_list":["post-5003367","aa_glossary","type-aa_glossary","status-publish","has-post-thumbnail","hentry","category-process"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003367","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary"}],"about":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/types\/aa_glossary"}],"author":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/users\/8027401"}],"replies":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/comments?post=5003367"}],"version-history":[{"count":0,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003367\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media\/8067461"}],"wp:attachment":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media?parent=5003367"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/categories?post=5003367"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/tags?post=5003367"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}