SKP’s Agile Cheatsheet: Part 02

SKP's Agile Cheatsheet is a three part series of articles focused on daily agile terminology, ideal to be printed out and pinned up near your workstation. Part 1 of this article is available here and you can download the PDF of this cheatsheet here.

Epic. An epic is a large user story. [Type – Agile Estimation / Agile Product Management]

Fibonacci Scale. 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. [Type – Agile Estimation / Agile Product Management]

Fishbone Diagram. The Fishbone Diagram (also called Ishikawa Diagram, Cause and Effect Diagram) got its name from its similarity of its shape to that of a fish skeleton. The Ishikawa Diagram relates to the seven basic tools of measurement, evaluation, control, and improvement of a production processes. Fishbone Diagrams are used to study, to display graphically, and analyze multiplicity of causes that influence the occurrence of a problem being solved and their impact. [Type – Agile Root Cause Analysis]

Information Radiator. “Information radiator” is the generic term for any of a number of handwritten, 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 information at a glance: count of automated tests, velocity, incident reports, continuous integration status, and so on. [Type – Agile Project Management]

Kanban. The Kanban Method is a means to design, manage and improve flow for knowledge work and allows teams to start where they are to drive evolutionary change. [Type – Agile Alternatives]  

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

Kano Model. The Kano Model (pronounced “Kah-no”) is an approach to prioritizing features on a product roadmap based on the degree to which they are likely to satisfy customers. ... Product managers often use the Kano Model to prioritize potential new features by grouping them into categories. [Type – Agile Product Management]

Large Scale Scrum (LeSS). LeSS is a lightweight (agile) framework for scaling Scrum to more than one team. It was extracted out of the experiences of Bas Vodde and Craig Larman while Scaling Agile development in many different types of companies, products, and industries over the last ten years. LeSS consists of the LeSS Principles, the framework, the guides, and a set of experiments. The LeSS framework is divided into two frameworks: Basic LeSS for 2-8 teams and LeSS Huge for 8+ teams. [Type – Agile for Large Teams]

Lean. It turns out that Lean projects are quite effective if they incorporate Agile concepts into their execution. After all, Lean means lean, without excess or waste, something that meets all that the Agile methodologies propose. Lean-Agile is a set of principles and practices for working that aims to minimise waste whilst maximising value. This enables organisations to make quality a priority in their products and services. (Credits to https://www.bluefruit.co.uk) [Type – Agile Alternatives]  

Load. 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 Management]

Managed Agile Development. The Managed Agile Development Framework described in this chapter is a project-level framework that is intended to provide a balance of agility combined with some level of predictability 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 development lifecycle model consisting of a blend of an adaptive agile development approach based on Scrum at the micro-level and a more traditional plan-driven approach at the macro-level, as shown below (Credits to O’Reilly Publishers) [Type – Hybrid Agile]

Milestone. An Agile milestone is a specific point in an Agile project that marks a significant stage of development. When you use milestones in Agile projects, there is a higher likelihood of your deliverables being on time — therefore they are an important feature in project management software. ( Credits: www.wrike.com ) [Type – Agile Project Management / Agile Product Management / Agile Development]

Minimum Viable Product (MVP). 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 automation, 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 Releases/Product Management]

MoSCoW Technique. The Moscow method is a prioritization technique used in management, business analysis, project management, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement; it is also known as MoSCoW prioritization or MoSCoW analysis. [Type – Agile Project/Product Management]

Pair Programming. Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently. [Type – Agile Development]

Pareto Chart. One of the core principles of Agile development is the Pareto Principle. It basically says 80% of the impact can be generated by focusing on 20% of the problems. Rapidly iterate on the set of problems by focusing on solving only the 20% that provide 80% impact each iteration quickly, faster and faster every time. Minimum effort maximum returns. The secret to success by achieving more with less. Do more by doing less. 80-20 rule helps move away from chaos and bring clarity part by part. Keeps you moving fast. (Credits – LinkedIn, Suhas Manangi) [Type – Agile Project Management, Agile Product Management]

Payback Period. Payback period is the amount of time required to recover the initial cost of an investment. 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.agilepm.se ) [Type – Agile Product Management]  

Product Backlog Refinement. Product Backlog Refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. [Type – Agile Product Management]  

Project Kick-off. 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 overarching strategy, project vision and scope, team roles and responsibilities, 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://tech.gsa.gov ) [Type – Agile Project Management].

Product Owner. The Product Owner (PO) is a member of the Agile Team responsible for defining Stories and prioritizing the Team Backlog to streamline the execution of program priorities while maintaining the conceptual and technical integrity of the Features or components for the team. [Type – Agile Product Management]

Program Increment. A Program Increment (PI) is a timebox during which an Agile Release Train (ART) delivers incremental 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 development Iterations, followed by one Innovation and Planning (IP) Iteration. [Type – Scaled Agile Framework]

Relative Sizing in Agile. Relative estimation is one of the several distinct flavors of estimation used in Agile teams, and consists of estimating tasks or user stories, not separately and in absolute units of time, but by comparison or by grouping of items of equivalent difficulty. [Type – Agile Estimation]  

First, the size of a task or story is what must be estimated. It’s made up of three factors:

1. Effort. How much work is required to complete this task?
2. Complexity. How difficult or complicated is this task?
3. Uncertainty. Do we know how to accomplish this task, or will we need to learn as we go?

The combination of these three factors is the story’s size. Second, the size is relative to the other stories your team may have on its plate. We find it’s easier and more effective to compare tasks and determine which is larger or smaller, rather than assign numbers or sizes to tasks independently without a reference point.

Retrospective. An Agile retrospective is a meeting that's held at the end of an iteration in Agile software development. During the retrospective, the team reflects on what happened in the iteration and identifies actions for improvement going forward. Each member of the team members answers the following questions:

• What worked well for us?
• What did not work well for us?
• What actions can we take to improve our process going forward?

The Agile retrospective can be thought of as a "lessons learned" meeting. The team reflects on how everything went and then decides what changes they want to make in the next iteration. The retrospective is team-driven, and team members should decide together how the meetings will be run and how decisions will be made about improvements. (Credits to TechTarget). [Type – Agile Product Management]