Fibonacci scale (agile)

In Agile software development, the Fibonacci scale consists of a sequence of numbers used for estimating the relative size of user stories in points. Agile Scrum is based on the concept of working iteratively in short sprints, typically two weeks long, where the requirements and development are continuously being improved. The Fibonacci sequence consists of numbers that are the summation of the two preceding numbers, starting with [0, 1]. Agile uses the Fibonacci sequence to achieve better results by reducing complexity, effort, and doubt when determining the development time required for a task, which can range from a few minutes to several weeks.[1]

Procedure

It is easier to determine the relative complexity of a task rather than figuring out how much time it requires. Due to this, when working with agile, a revised Fibonacci scale is used in terms of points to estimate the work, as opposed to the traditional measurement of time.[2]

In one method commonly used to calculate the size of stories in points, a process like the game of Planning Poker, the following process is used:

  1. The Product Owner sits down with the team to estimate the user stories.
  2. Each member estimates a number on the Fibonacci scale that he/she believes represents the size of the task.
  3. All members disclose their number at the same time (to avoid being influenced by each other's estimates).
  4. Any differences in the numbers will be followed by a discussion until a consensus is reached.
  5. Each user story is added to a bucket which represents the corresponding point on the Fibonacci scale.
  6. The steps above are repeated for all user stories.
  7. The buckets are added to the backlog.

Giving each member the opportunity to think individually reduces pressure and may result in a more accurate representation of the feature’s size.

In another commonly used method, a process like the game of Two Pass Relative Sizing,[3] also known as the Steve Bockman Method[4] and the Team Estimation Game,[5] the following process is used:

  1. The product manager sits down with the team to estimate a project's worth of user stories, which are provided to the team in a stack of 3x5 or 4x6 cards.
  2. The first team member reads the first card and places it on the table, passing the remaining stack to the next team member.
  3. The second team member reads the second card, may declare a belief that the story is larger or smaller than the card already on the table or may ask the team for help in so determining, and establishes which direction is smaller or larger by placing the card to the left or right of the first card; and passes the remaining stack to the next team member.
  4. The third team member has a choice: to move the position of the second card; or to read the third card, declare a belief that the story is larger than the first two, smaller than the first two; or belongs between the first two; and passes the remaining stack to the next team member.
  5. When all the cards are on the table - if the product manager truly provided a project's worth, then there are likely 60 or 100 or 130 cards and the team has had to "snake" them to fit them all - then the team begins with the smallest story and assigns it a "1", continuing to assign "1"s to subsequent stories until they see an obvious jump to "2"s, and then to "3"s, "5"s, "8"s, and so on. With the result that the "snake" of cards is now numbered from the smallest story, a "1", to the largest epic, a "100".

This method has the advantages that numbers are not used until the second pass; that no guessing is required for the first story read as to how big a "5" or "8" or "3" is;[4] that stories are truly ordered and numbered relative to each other; and when not everyone can estimate the entire story.[6]

Regardless of method, as the team goes through multiple sprints and the estimation process is improved, the product manager will be able to determine a stable velocity. The velocity is determined by calculating the number of story points completed in each iteration.[1]

Significance

People estimate user stories with smaller points more accurately than user stories that have higher costs associated with them. As the numbers increase, the difference between two succeeding numbers increases exponentially and leads to less accurate estimates.[7]

  • Using Fibonacci series is helpful in this scenario because the larger user stories (i.e. stories of size greater than 8) that tend to lead to inconsistent estimates between each team member can be grouped to the nearest estimated Fibonacci number of the corresponding bucket in the backlog.
  • In case of small user stories the bucket difference is small and hence the final cost of resource and time can be finalized more accurately.

One good way to estimate the cost is to express it in terms of multiples of other known user stories' costs. This way, it will be easier for each team member to estimate the relative cost. The estimation process of comparing a story with two previously estimated user stories is called triangulation.[7]

The product manager can include a "0" value in the scale indicating that the user stories need very little time or resources.[7] However, the user story that was assigned 0 cost cannot be used as a relative scale to estimate the cost of other user stories (i.e. we cannot say a story is 10 times harder than a story of size 0).

An advantage of Fibonacci sequence is that it allows developers to disaggregate a user story from one large bucket into two preceding buckets (since a bucket is formed by adding the size of two preceding buckets).[7] This process helps to create optimal user stories.

Other estimation scales
  • Linear scale – Increments in a fixed value
  • T-shirt size – (S < M < L < XL < XXL < XXXL)
  • Playing cards – Mostly used in planning poker (A < 2 < 3…)
  • Exponential series - ({an} for some a and for all integer n>0)

See also

References
  1. "Sizing and Estimates Overview | CA Agile Central Help". help.rallydev.com. Retrieved 2017-02-10.
  2. "Agile Project Management (PDF Download Available)". ResearchGate. Retrieved 2017-02-10.
  3. Bockman, Steve (2015-01-25). Practical Estimation. Amazon Digital Services. ASIN B00SS794IQ.
  4. "Story Sizing: A better start than planning poker". agilelearninglabs. Retrieved 2018-07-08.
  5. "How to play the Team Estimation Game". agilelearninglabs. Retrieved 2018-07-08.
  6. "Team Estimation". netobjectives. Retrieved 2018-07-09.
  7. Cohn, Mike (2005-11-01). Agile Estimating and Planning. Pearson Education. ISBN 9780132703109.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.