INVEST (mnemonic)

Last updated

The INVEST mnemonic for Agile software development projects was created by Bill Wake [1] as a reminder of the characteristics of a good quality Product Backlog Item (commonly written in user story format, but not required to be) or PBI for short. Such PBIs may be used in a Scrum backlog, Kanban board or XP project.

Contents

LetterMeaningDescription
I Independent The PBI should be self-contained.
N Negotiable PBIs are not explicit contracts and should leave space for discussion.
V Valuable A PBI must deliver value to the stakeholders.
E Estimable You must always be able to estimate the size of a PBI.
S Small PBIs should not be so big as to become impossible to plan/task/prioritize within a level of accuracy.
T Testable The PBI or its related description must provide the necessary information to make test development possible.

Independent

One of the characteristics of Agile Methodologies such as Scrum, Kanban or XP is the ability to move PBIs around, taking into account, amongst other criteria, their relative priority. When PBIs are tightly dependent, it might be possible to combine them into a single PBI.

Negotiable

According to Agile methodology, while the PBI lies in the product backlog it can be rewritten or even discarded, depending on business, market, technical or any other type of requirement by team members.

Most notably though, Negotiability relates to the degree to which the Developer has freedom to negotiate the detail of the solution with the Business once in development. A story should not form a rigid contract detailing the design, but should instead talk of business outcomes the user will be able to conduct once implemented. The amount of 'wiggle room' the analyst leaves the Developer in this regard is a measure of its Negotiability. A highly negotiable story therefore typically aims to keep away from detailed UI design, certainly insofar as the Value Statement and Acceptance Criteria are concerned. Stories are not detailed specifications and nor should they aim to be.

Valuable

The aim of Agile Methodology being to continuously deliver valuable software, the PBI should bring value to the stakeholder. [2]

Sometimes a story might not result in a complete shippable feature in its own right, and it may simply be a measurable step towards that goal. Nevertheless, the story must at least be demonstrable to the stakeholder and show that progress (i.e. something of value) has been delivered. For example, it would be acceptable for a coded/text response back from a central service to be simply shown in the user's UI (as text) to demonstrate that data had been sent to - and accepted by that service - and have a better representation of that response to be covered in another story. In this sense, the story was demonstrable and achieved something of business value, albeit perhaps not the final iteration of the design.

Estimable

Originally, Bill Wake reasoned that if a PBI size cannot be estimated, it will never be planned or tasked, and thus, it will never become part of an iteration. By this reasoning, PBI items should be capable of being estimated at some point. Note that this does not mean a PBI should in fact be estimated during the initial creation of the PBI, but only that it describes something which could be estimated.

Subsequently, to the introduction of INVEST, the "No Estimates" movement has gained traction in moving product owners away from the belief that a PBI must have been estimated in order to be planned or tasked. Many software practitioners will take on work without estimating the effort involved, as long as the item is narrowed sufficiently in scope. [3] Bill Wake has expressed that were he to re-pick INVEST today, he would remove "Estimability" and utilize the "E" to instead emphasize an aspect of the "V for Valuable" criteria. [4]

A note of caution: Estimability is the most-abused aspect of INVEST (that is, the most energy spent for the least value). If I could re-pick, we’d have “E = External”; see the discussion under “V for Valuable”.

— Bill Wake, https://xp123.com/articles/estimable-stories-in-the-invest-model/

"Estimable" as 'the capability to be estimated' is an American English definition. To avoid confusion with the British English meaning of 'worthy of esteem', some versions of the model use the reference "Estimate-able" which also is not a defined dictionary entry. Allen Holub has suggested that the British English meaning should be embraced, seeing the process of estimation as being harmful to the software development process. [5]

Small

Try to keep your PBI sizes to typically a few person-days and at most a few person-weeks (a good rule of thumb is that any single Product Backlog Item does not take more than 50% of an iteration; for example a single item won't take more than 5 days for a 2-week / 10 day sprint). Anything beyond that range should be considered too large to be estimated with a good level of certainty - these large PBIs may be called "Epics", where an Epic will take more than one iteration to deliver and, necessarily, will need to be broken down into smaller PBIs that can fit comfortably within Iterations. There's no problem in starting with epic PBIs, as long as they are broken down when the time to place them in an iteration backlog comes closer. This implements Lean software development's Just In Time analysis concept.

Testable

A PBI should only be considered DONE, among other things, if it was tested successfully. If one cannot test a PBI due to lack of information or access (see "Estimable" above), the PBI should not be considered a good candidate to be part of an iteration Backlog. This is especially true for teams employing TDD - Test Driven Development.

See also

Related Research Articles

<span class="mw-page-title-main">Acceptance testing</span> Test to determine if the requirements of a specification or contract are met

In engineering and its various subdisciplines, acceptance testing is a test conducted to determine if the requirements of a specification or contract are met. It may involve chemical tests, physical tests, or performance tests.

The rational unified process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.

In software development, agile practices include requirements, discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s). Popularized in the 2001 Manifesto for Agile Software Development, these values and principles were derived from, and underpin, a broad range of software development frameworks, including Scrum and Kanban.

In agile principles, timeboxing allocates a maximum unit of time to an activity, called a timebox, within which a planned activity takes place. It is used by agile principles-based project management approaches and for personal time management.

Lean software development is a translation of lean manufacturing principles and practices to the software development domain. Adapted from the Toyota Production System, it is emerging with the support of a pro-lean subculture within the agile community. Lean offers a solid conceptual framework, values and principles, as well as good practices, derived from experience, that support agile organizations.

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 specific management software. Depending on the product, user stories may be written by different stakeholders like client, user, manager, or development team.

Agile modeling (AM) is a methodology for modeling and documenting software systems based on best practices. It is a collection of values and principles that can be applied on an (agile) software development project. This methodology is more flexible than traditional modeling methods, making it a better fit in a fast-changing environment. It is part of the agile software development tool kit.

A product manager (PM) is a professional role that is responsible for the development of products for an organization, known as the practice of product management. Product managers own the product strategy behind a product, specify its functional requirements, and manage feature releases. Product managers coordinate work done by many other functions, and are ultimately responsible for product outcomes.

Extreme programming (XP) is an agile software development methodology used to implement software systems. 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">Scrum (software development)</span> Management framework

Scrum is an agile team collaboration framework commonly used in software development and other industries.

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.

<span class="mw-page-title-main">Kanban (development)</span> Software development methodology

Kanban is a lean method to manage and improve work across human systems. This approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks.

<span class="mw-page-title-main">Kanban board</span> Main tool used to implement the kanban project management methodology

A kanban board is one of the tools that can be used to implement kanban to manage work at a personal or organizational level.

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.

eXtreme Manufacturing (XM) is an iterative and incremental framework for manufacturing improvement and new product development that was inspired by the software development methodology Scrum and the systematic waste-elimination (lean) production scheduling system Kanban(かんばん ).

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.

The scaled agile framework (SAFe) is a set of organization and workflow patterns intended to guide enterprises in scaling lean and agile practices. Along with disciplined agile delivery (DAD) and S@S (Scrum@Scale), SAFe is one of a growing number of frameworks that seek to address the problems encountered when scaling beyond a single team.

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.

References

  1. ↑ Bill Wake's original article: INVEST in Good Stories, and SMART Tasks
  2. ↑ Principles behind the Agile Manifesto
  3. ↑ "The NoEstimates Movement".
  4. ↑ "Estimable Stories in the INVEST Model - XP123".
  5. ↑ Event storming - Allen Holub (Holub Associates), O'Reilly Software Architecture Conference, June 10–13, 2019
  1. Jeff Sutherland's Blog
  2. https://agileforall.com/new-to-agile-invest-in-good-user-stories/
  3. https://www.agilealliance.org/glossary/invest
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.