Fibonacci scale (agile)

Last updated

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]

Contents

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 that 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 establishing 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 advantage 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 the 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]

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 the 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

See also

Related Research Articles

<span class="mw-page-title-main">Card game</span> Game using playing cards as the primary device

A card game is any game using playing cards as the primary device with which the game is played, be they traditional or game-specific. Countless card games exist, including families of related games. A small number of card games played with traditional decks have formally standardized rules with international tournaments being held, but most are folk games whose rules may vary by region, culture, location or from circle to circle.

In poker, pot odds are the ratio of the current size of the pot to the cost of a contemplated call. Pot odds are compared to the odds of winning a hand with a future card in order to estimate the call's expected value. The purpose of this is to statistically guide a player's decision between the options of call or fold. Raising is an alternative to place this decision on the opponent.

<span class="mw-page-title-main">Cheating in poker</span>

Cheating in poker is any behavior outside the rules of poker that is intended to give an unfair advantage to one or more players.

The Constructive Cost Model (COCOMO) is a procedural software cost estimation model developed by Barry W. Boehm. The model parameters are derived from fitting a regression formula using data from historical projects.

The Personal Software Process (PSP) is a structured software development process that is designed to help software engineers better understand and improve their performance by bringing discipline to the way they develop software and tracking their predicted and actual development of the code. It clearly shows developers how to manage the quality of their products, how to make a sound plan, and how to make commitments. It also offers them the data to justify their plans. They can evaluate their work and suggest improvement direction by analyzing and reviewing development time, defects, and size data. The PSP was created by Watts Humphrey to apply the underlying principles of the Software Engineering Institute's (SEI) Capability Maturity Model (CMM) to the software development practices of a single developer. It claims to give software engineers the process skills necessary to work on a team software process (TSP) team.

Cost estimation in software engineering is typically concerned with the financial spend on the effort to develop and test the software, this can also include requirements review, maintenance, training, managing and buying extra equipment, servers and software. Many methods have been developed for estimating software costs for a given project.

Mental poker is the common name for a set of cryptographic problems that concerns playing a fair game over distance without the need for a trusted third party. The term is also applied to the theories surrounding these problems and their possible solutions. The name comes from the card game poker which is one of the games to which this kind of problem applies. Similar problems described as two party games are Blum's flipping a coin over a distance, Yao's Millionaires' Problem, and Rabin's oblivious transfer.

In software development and product management, a user story is an informal, natural language description of features of a software system. They are written from the perspective of an end user or user of a system, and may be recorded on index cards, Post-it notes, or digitally in project management software. Depending on the project, user stories may be written by different stakeholders like client, user, manager, or development team.

In software engineering, behavior-driven development (BDD) is a software development process that goes well with agile software development process that encourages collaboration among developers, quality assurance experts, and customer representatives in a software project. It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave. It emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

Extreme programming (XP) is an agile software development methodology used to implement software projects. This article details the practices used in this methodology. Extreme programming has 12 practices, grouped into four areas, derived from the best practices of software engineering.

<span class="mw-page-title-main">Unified Process</span> Object oriented software development process framework

The unified software development process or unified process is an iterative and incremental software development process framework. The best-known and extensively documented refinement of the unified process is the rational unified process (RUP). Other examples are OpenUP and agile unified process.

Histograms are most commonly used as visual representations of data. However, Database systems use histograms to summarize data internally and provide size estimates for queries. These histograms are not presented to users or displayed visually, so a wider range of options are available for their construction. Simple or exotic histograms are defined by four parameters, Sort Value, Source Value, Partition Class and Partition Rule. The most basic histogram is the equi-width histogram, where each bucket represents the same range of values. That histogram would be defined as having a Sort Value of Value, a Source Value of Frequency, be in the Serial Partition Class and have a Partition Rule stating that all buckets have the same range.

<span class="mw-page-title-main">Planning poker</span> Technique for estimating

Planning poker, also called Scrum poker, is a consensus-based, gamified technique for estimating, mostly used for timeboxing in Agile principles. In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. The cards are revealed, and the estimates are then discussed. By hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.

In project management, accurate estimates are the basis of sound project planning. Many processes have been developed to aid engineers in making accurate estimates, such as

The following is a glossary of poker terms used in the card game of poker. It supplements the glossary of card game terms. Besides the terms listed here, there are thousands of common and uncommon poker slang terms. This is not intended to be a formal dictionary; precise usage details and multiple closely related senses are omitted here in favor of concise treatment of the basics.

In software engineering, a software development process is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. It is also known as a software development life cycle (SDLC). The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

Velocity is a metric for work done, which is often used in agile software development.

Agile Business Intelligence (BI) refers to the use of Agile software development for BI projects to reduce the time it takes for traditional BI to show value to the organization, and to help in quickly adapting to changing business needs. Agile BI enables the BI team and managers to make better business decisions, and to start doing this more quickly.

Disciplined agile delivery (DAD) is the software development portion of the Disciplined Agile Toolkit. DAD enables teams to make simplified process decisions around incremental and iterative solution delivery. DAD builds on the many practices espoused by advocates of agile software development, including scrum, agile modeling, lean software development, and others.

Scrumban is an Agile aligned approach to product delivery which is a hybrid of Scrum and Kanban. Scrumban was originally designed as a way to transition from Scrum to Kanban.

References

  1. 1 2 "Sizing and Estimates Overview | CA Agile Central Help". help.rallydev.com. Retrieved February 10, 2017.
  2. ↑ "Agile Project Management (PDF Download Available)". ResearchGate. Retrieved February 10, 2017.
  3. ↑ Bockman, Steve (January 25, 2015). Practical Estimation. Amazon Digital Services. ASIN   B00SS794IQ.
  4. 1 2 "Story Sizing: A better start than planning poker". agilelearninglabs. Retrieved July 8, 2018.
  5. ↑ "How to play the Team Estimation Game". agilelearninglabs. Retrieved July 8, 2018.
  6. ↑ "Team Estimation". netobjectives. April 12, 2018. Retrieved July 9, 2018.
  7. 1 2 3 4 Cohn, Mike (November 1, 2005). Agile Estimating and Planning. Pearson Education. ISBN   9780132703109.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.