SKP's Daily Agile Terms Cheat Sheet by sumith.puri

An acceptance test is a formal descri­ption of the behaviour of a software product, generally expressed as an example or a usage scenario. Several different notations and approaches have been proposed for such examples or scenarios. In many cases the aim is that it should be possible to automate the execution of such tests by a software tool, either ad-hoc to the develo­pment team or off the shelf. [Type – Software Testing / Product Manage­ment]

C4 Model documents the archit­ecture of a software system, by showing multiple points of view that explain the decomp­osition of a system into containers and compon­ents, the relati­onship between these elements, and, where approp­riate, the relation with its users. The viewpoints are organized according to their hierar­chical level: Context Diagrams, Container Diagrams, Component Diagrams, Code Diagrams. [Type – Agile Modelling, Agile Archit­ecture, System Design]

Antipatterns are common solutions to common problems where the solution is ineffe­ctive and may result in undesired conseq­uences. An antipa­ttern is different from bad practice under certain circum­sta­nces. [Type – Patterns in Problem Solving]

The team displays, somewhere on a wall of the project room, a large graph relating the quantity of work remaining (on the vertical axis) and the time elapsed since the start of the project (on the horizo­ntal, showing future as well as past). This consti­tutes an “Infor­mation Radiator“, provided it is updated regularly. Two variants exist, depending on whether the amount graphed is for the work remaining in the iteration (“Sprint Burndown”) or more commonly the entire project (“Product Burndo­wn”). [Type – Agile Project Manage­ment]

Capacity is how much availa­bility the team has for the sprint. This may vary based on team members being on vacation, ill, etc. The team should consider capacity in determ­ining how many product backlog items to plan for a sprint. [Type – Agile Project Management / Agile Estima­tion]

Continuous Delivery is the ability to get changes of all types—­inc­luding new features, config­uration changes, bug fixes and experi­men­ts—into produc­tion, or into the hands of users, safely and quickly in a sustai­nable way. Our goal is to make deploy­men­ts—­whether of a large-­scale distri­buted system, a complex production enviro­nment, an embedded system, or an app—pr­edi­ctable, routine affairs that can be performed on demand. We achieve all this by ensuring our code is always in a deployable state, even in the face of teams of thousands of developers making changes daily. We thus eliminate the integr­ation, testing and hardening phases that tradit­ionally followed “dev complete”, as well as code freezes. [Type – Agile Develo­pment / Agile Releases]

Continuous develo­pment, “like agile, began as a software develo­pment method­ology. Rather than improving software in one large batch, updates are made contin­uously, piece-­by-­piece, enabling software code to be delivered to customers as soon as it is completed and tested.Co­mpanies that can succes­sfully implement Continuous Develo­pment throughout their organi­zation often find dramatic strategic benefits,” as described in the Harvard Business Review. [Type – Agile Develo­pment / Agile Releases]

The Cumulative Flow Diagram (also known as CFD) is one of the most advanced Kanban and Agile analytics charts. It provides a concise visual­ization of the three most important metrics of your flow: Cycle Time, Throug­hput, Work in Progress. Its main purpose is to show you how stable your flow is and help you understand where you need to focus on making your process more predic­table. It gives you quanti­tative and qualit­ative insight into past and existing problems and can visualize massive amounts of data. [Type – Agile Project Manage­ment]

The definition of done is an agreed upon list of the activities deemed necessary to get a product increment, usually repres­ented by a user story, to a done state by the end of a sprint. [Type – Agile Manage­ment]

Disciplined agile delivery (DAD) is the software develo­pment portion of the Discip­lined Agile Toolkit. DAD enables teams to make simplified process decisions around increm­ental and iterative solution delivery. DAD builds on the many practices espoused by advocates of Agile Software Develo­pment, including Scrum, Agile Modeling, Lean Software Develo­pment, and Others. The primary reference for discip­lined agile delivery is the book Choose Your WoW! written by Scott Ambler and Mark Lines. [Type – Agile Variant]

Earned Value Management (EVM) is a project management technique that measures the technical perfor­mance, cost and schedule of a project against planned object­ives. The result is a simple set of metrics that provides early warnings of perfor­mance issues, allowing for timely and approp­riate adjust­ments. EVM also improves the definition of project scope and provides valuable metrics for commun­icating progress to stakeh­olders. To implement EVM, you need to measure some basic metrics like a valuation of planned work, called planned value (PV). Agile EVM is a lightw­eight and easy to use adaptation of the tradit­ional Earned Value Management technique which provides the benefits of tradit­ional Earned Value Management for Scrum. [Type – Agile Project Management / Agile Analysis]

In Agile software develo­pment, 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 iterat­ively in short sprints, typically two weeks long, where the requir­ements and develo­pment are contin­uously 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 comple­xity, effort, and doubt when determ­ining the develo­pment time required for a task, which can range from a few minutes to several weeks. [Type – Agile Estimation / Agile Product Manage­ment]

“Information radiator” is the generic term for any of a number of handwr­itten, drawn, printed or electronic displays which a team places in a highly visible location, so that all team members as well as passers-by can see the latest inform­ation at a glance: count of automated tests, velocity, incident reports, continuous integr­ation status, and so on. [Type – Agile Project Manage­ment]

A Kanban Board is a visual workflow tool consisting of multiple columns. Each column represents a different stage in the workflow process. [Type – Agile Altern­atives]

LeSS is a lightw­eight (agile) framework for scaling Scrum to more than one team. It was extracted out of the experi­ences of Bas Vodde and Craig Larman while Scaling Agile develo­pment in many different types of companies, products, and industries over the last ten years. LeSS consists of the LeSS Princi­ples, the framework, the guides, and a set of experi­ments. The LeSS framework is divided into two framew­orks: Basic LeSS for 2-8 teams and LeSS Huge for 8+ teams. [Type – Agile for Large Teams]

Load is the team's committed value of the number of points the team intends to deliver in a sprint or PI. It is based on team capacity and the stories available in the backlog. [Type – Agile Project Manage­ment]

The Managed Agile Develo­pment Framework described in this chapter is a projec­t-level framework that is intended to provide a balance of agility combined with some level of predic­tab­ility and control. It is intended for companies that are unable or not ready to move to a more complete top-to­-bottom agile model such as the Scaled Agile Framework. It is a hybrid software develo­pment lifecycle model consisting of a blend of an adaptive agile develo­pment approach based on Scrum at the micro-­level and a more tradit­ional plan-d­riven approach at the macro-­level, as shown below (Credits to O’Reilly Publis­hers) [Type – Hybrid Agile]

A Minimum Viable Product is, as Eric Ries said, the “Version of a New Product which allows a team to collect the maximum amount of validated learning about customers with the Least Effort.” This validated learning comes in the form of whether your customers will purchase your product. A key premise behind the idea of MVP is that you produce an actual product (which may be no more than a landing page, or a service with an appearance of automa­tion, but which is fully manual behind the scenes) that you can offer to customers and observe their actual behavior with the product or service. Seeing what people do with respect to a product is much more reliable than asking people what they would do. [Type – Agile Releas­es/­Product Manage­ment]

Pair progra­mming is an agile software develo­pment technique in which two progra­mmers work together at one workst­ation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two progra­mmers switch roles freque­ntly. [Type – Agile Develo­pment]

Payback period is the amount of time required to recover the initial cost of an invest­ment. Let’s say for example you make an investment of $100,000 and you will gain a profit of $10,000 per month once the feature is released. Then the payback period is 10 months. ( Credits to www.ag­ile­pm.se ) [Type – Agile Product Manage­ment]

Project Kick-off or Product Feature Kick-off or Agile Kick-off - The Agile Project Kick-off agenda should convey the high-level project overview and overar­ching strategy, project vision and scope, team roles and respon­sib­ili­ties, as well as the Agile approach and supporting ceremonies to be used. At the end of the kick-off meeting, the team should have an action plan for next steps. ( Credits to https:­//t­ech.gs­a.gov ) [Type – Agile Project Manage­ment]

A Program Increment (PI) is a timebox during which an Agile Release Train (ART) delivers increm­ental value in the form of working, tested software and systems. PIs are typically 8 – 12 weeks long. The most common pattern for a PI is four develo­pment Iterat­ions, followed by one Innovation and Planning (IP) Iteration. [Type – Scaled Agile Framework]

An Agile retros­pective is a meeting that's held at the end of an iteration in Agile software develo­pment. During the retros­pec­tive, the team reflects on what happened in the iteration and identifies actions for improv­ement going forward.

This refers to a testing strategy that uses 'defined risk' to determine testing goals. In other words, the risk-based testing approach organizes testing efforts in ways that lower the residual level of product risk when the software goes into produc­tion. (Credits to Browse­rStack) [Type – Agile Testing]

Use this activity to set the stage and/or gather data in an iteration retros­pec­tive. Highlight how satisfied team members are with a focus area. Provide a visual picture of status in a particular area to help the team have deeper discus­sions and analysis. Acknow­ledge differ­ences in perspe­ctive among team members. [Type – Agile Project Manage­ment]

The schedule variance, SV, is a measure of the confor­mance of the actual progress to the planned progress: SV = EV – PV. A major criticism of the standard EVM is that the schedule variance is measured in cost units, not time. ( Refer to Earned Value Management Above, Credits to www.pm­i.org ) [Type – Agile Project Manage­ment]

The scrum master is respon­sible for ensuring the team lives agile values and principles and follows the practices that the team agreed they would use. [Type – Agile Project Management / Agile Develo­plment]

A spaghetti diagram is defined as a visual repres­ent­ation using a continuous flow line tracing the path of an item or activity through a process. As a process analysis tool, the continuous flow line enables process teams to identify redund­ancies in the work flow and opport­unities to expedite process flow. [Type – Agile Root Cause Analysis / Agile Project Manage­ment]

Sprint planning is an event that occurs at the beginning of a sprint where the team determines the product backlog items, they will work on during that sprint. [Type – Agile Projec­t/P­roduct Manage­ment]

A user story is a tool in Agile software develo­pment used to capture a descri­ption of a software feature from a user's perspe­ctive. ... A user story helps to create a simplified descri­ption of a requir­ement. The purpose of a user story is to write down how a project will deliver value back to the end user. [Type – Agile Product Manage­ment]

Agile teams generally prefer to express estimates in units other than the time-h­onored “man-h­ours.” Possibly the most widespread unit is “story points.” [Type – Agile Estima­tion]

Spikes are a type of explor­ation Enabler Story in SAFe. Defined initially in Extreme Progra­mming (XP), they represent activities such as research, design, invest­iga­tion, explor­ation, and protot­yping.

It is a different name for Test Driven Develo­pment (Refer Above)

At the end of each iteration, the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity. [Type – Agile Project Manage­ment]

Asana helps you plan, organize, and manage Agile projects and Scrum sprints in a tool that's as flexible and collab­orative as your team. From Boards to Timelines and custom fields to depend­encies, Asana has the features your team needs to build fast and ship often. [Type – Agile Projec­t/P­roduct Manage­ment]

Mingle, an Agile Project Management product, was originally created at Though­tWorks in 2007. In July 2018, its retirement was announced. In June 2020, the Mingle codebase was made available. It is now at https:­//g­ith­ub.c­om­/mi­ngl­e/m­ingle . [Type – Agile Projec­t/P­roduct Manage­ment]

Track time spent on Asana tasks, monitor produc­tivity across multiple projects, and easily automate payroll calcul­ations. [Type – Agile Project Manage­ment]

Rally is one of the most compre­hensive agile project management tools, and it helps you track your projects' progress Iterat­ively, assign stories to iterat­ions, split stories to tasks, tag defects to stories etc. The tool also helps you monitor your teams' progress. [Type – Agile Projec­t/P­roduct Manage­ment]