{"id":5003293,"date":"2015-12-16T23:35:25","date_gmt":"2015-12-17T07:35:25","guid":{"rendered":"https:\/\/aadev22.local\/?post_type=aa_glossary&p=5003293"},"modified":"2022-08-29T16:19:46","modified_gmt":"2022-08-29T23:19:46","slug":"points-estimates-in","status":"publish","type":"aa_glossary","link":"https:\/\/agilealliance.org\/glossary\/points-estimates-in\/","title":{"rendered":"Points (estimates in)"},"content":{"rendered":"

Agile teams generally prefer to express\u00a0estimates<\/a>\u00a0in units other than the time-honored \u201cman-day\u201d or \u201cman-hour.\u201d Possibly the most widespread unit is \u201cstory points.\u201d<\/p>\n

One of the chief reasons is the use of\u00a0velocity<\/a>\u00a0for planning purposes. \u201cVelocity,\u201d in the sense Agile teams use the term, has no preferred unit of measurement, it is a dimensionless quantity. Velocity allows teams to compute the expected remaining duration of the project, as a number of\u00a0iterations<\/a>, each iteration delivering some amount of features.<\/p>\n

Another important reason has to do with the social and psychological aspects of estimation: using units such as story points, emphasizing relative difficulty over an absolute duration, relieves some of the tensions that often arise between developers and managers around estimation: for instance, asking developers for an estimate then holding them accountable as if it had been a firm commitment.<\/p>\n

Also Known As<\/h2>\n

Reflecting a long-standing lack of consensus, not merely in the Agile community but in the broader arena of software development, a variety of terms are in use and Agile teams tend to create new ones with very little provocation.<\/p>\n

\u201cStory points\u201d is standard if any particular term is; \u201cGummi bears\u201d have been popular since the early days of Extreme Programming<\/a>, and \u201cNebulous Units of Time\u201d (or NUTs) have enjoyed some currency.<\/p>\n

Common Pitfalls<\/h2>\n

The most egregious mistake is probably to invest too much time or too much debate into the choice of a unit for estimates, insofar as scheduling based on velocity makes this unit inconsequential.<\/p>\n

Origins<\/h2>\n

\u201cWhat units are estimates expressed in\u201d has been a perennial topic of discussion in the Agile community. The jargon of early Extreme Programming practitioners remained strongly anchored in estimates expressed as durations, labeled \u201cideal time\u201d but adjusted via a \u201cload factor\u201d.<\/p>\n

Starting shortly before the year 2000 the whimsical term \u201cgummi bears\u201d then gained popularity, as did the more neutral \u201cstory points,\u201d both signaling the community\u2019s widespread disfavor of even hinting at absolute durations when providing estimates at the task or\u00a0story<\/a>\u00a0levels.<\/p>\n

Even among the originators of Extreme Programming, however, the consensus was never total, witness Kent Beck\u2019s professed preference for \u201creal hours\u201d estimates in the mid-2000s.<\/p>\n