Show Menu
Cheatography

SKP's Daily Agile Terms Cheat Sheet by

Daily Terminologies used in Agile Software Development - Useful for all Software Developers, Engineering Managers, Scrum Masters, Software Architects, Product Managers and Agile Practitioners.

Agile Develo­pment Terms & Termin­ologies [A-C]

Acceptance Testing
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]
Affinity Diagram
An affinity diagram is a method used to organize many ideas into groups with common themes or relati­ons­hips. Affinity diagrams are tools for analysing large amounts of data and discov­ering relati­onships that allow a design direction to be establ­ished based on the associ­ations. [Type – Brains­tor­ming, Agile Process, Sprint Retros­pec­tive]
Agile C4Model
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]
Agile Unified Process
Agile Unified Process (AUP) is a simplified version of the Rational Unified Process (RUP) developed by Scott Ambler. It describes a simple, easy to understand approach to developing business applic­ation software using agile techniques and concepts yet still remaining true to the RUP. The AUP applies agile techniques including Test-D­riven Develo­pment (TDD), Agile Modeling (AM), Agile Change Manage­ment, and Database Refact­oring to Improve Produc­tivity. [Type – Agile Variant / Develo­pment Process]
Anti-P­attern
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]
Archit­ectural Spike
An Archit­ectural Spike is a technical risk-r­edu­ction technique popula­rized by Extreme Progra­mming (XP) where you write just enough code to explore the use of a technology or technique that you're unfamiliar with. [Type – Agile Stories / Protot­yping]
Burn Down Charts
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]
Burn Up Charts
By 2002, the Burndown Chart gained enough popularity among the Scrum community, as well as altern­atives such as the “Burnup” which merely inverts the vertical direction, or the more sophis­ticated “Cumul­ative Flow Diagram“, which most closely resembles a Burnup but appears to be an Indepe­ndent Invention. [Type – Agile Project Manage­ment]
Capacity
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]
Constr­aints
A constraint is a restri­ction on the degree of freedom you have in providing a solution. Constr­aints are effect­ively global requir­ements, such as limited develo­pment resources or a decision by senior management that restricts the way you develop a system. Constr­aints can be economic, political, technical, or enviro­nmental and pertain to your project resources, schedule, target enviro­nment, or to the system itself. . Constr­aints are documented in a similar manner to business rules and technical requir­ements. [Type – Agile Develo­pment / Limita­tions in Develo­pment]
Continuous Delivery
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 Deployment
Continuous deployment aims to reduce the time elapsed between writing a line of code and making that code available to users in produc­tion. To achieve continuous deploy­ment, the team relies on infras­tru­cture that automates and instru­ments the various steps leading up to deploy­ment, so that after each integr­ation succes­sfully meeting these release criteria, the live applic­ation is updated with new code. [Type – Agile Develo­pment / Agile DevOps]
Continuous Develo­pment
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]
Continuous Integr­ation
Continuous Integr­ation is the practice of merging code changes into a shared repository several times a day to release a product version at any moment. This requires an integr­ation procedure which is reprod­ucible and automated. [Type – Agile Develo­pment / Agile Change Manage­ment]
Cumulative Flow Diagram
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]

Agile Develo­pment Terms & Termin­ologies [D-L]

Definition of Done (DoD)
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]
Demo
Demo or Sprint Demo or Sprint Review or Agile Demo (Terms with only few Subtle Differ­ences) : [1] An activity of a sprint review where the completed (done) product backlog items are demons­trated with the goal of promoting an inform­ati­on-rich discussion between the Scrum team and other sprint review partic­ipants. [2.] A term that is frequently used synony­mously to refer to the entire sprint review. [Type – Agile Develo­pment]
Discip­lined Agile Delivery (DAD)
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]
Dreyfus Model
The Dreyfus Model is based on the idea that different people, no matter their profes­sion, can be divided into 5 categories - from novice to expert. In addition, each category has a specific set of skills and, most import­antly, different approaches to solving problems. Newbie (Novice) or Beginner, Advanced Beginner, Competent, Profic­ient, Expert. It can be used in Agile for Scaling People. [Type – Agile Project Manage­ment]
Earned Value Management
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]
Epic
An epic is a large user story. [Type – Agile Estimation / Agile Product Manage­ment]
Fibonacci Scale
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]
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 measur­ement, evalua­tion, control, and improv­ement of a production processes. Fishbone Diagrams are used to study, to display graphi­cally, and analyze multip­licity of causes that influence the occurrence of a problem being solved and their impact. [Type – Agile Root Cause Analysis]
Inform­ation Radiator
“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]
Kanban
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]
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 Altern­atives]
Kano Model
The Kano Model (prono­unced “Kah-no”) is an approach to priori­tizing 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 catego­ries. [Type – Agile Product Manage­ment]
Large Scale Scrum (LeSS)
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]
Lean
It turns out that Lean projects are quite effective if they incorp­orate Agile concepts into their execution. After all, Lean means lean, without excess or waste, something that meets all that the Agile method­ologies propose. Lean-Agile is a set of principles and practices for working that aims to minimise waste whilst maximising value. This enables organi­sations to make quality a priority in their products and services. (Credits to https:­//w­ww.b­lu­efr­uit.co.uk) [Type – Agile Altern­atives]
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 Manage­ment]

Agile Develo­pment Terms & Termin­ologies [M-R]

Managed Agile Develo­pment
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]
Milestone
An Agile milestone is a specific point in an Agile project that marks a signif­icant stage of develo­pment. When you use milestones in Agile projects, there is a higher likelihood of your delive­rables being on time — therefore they are an important feature in project management software. ( Credits: www.wr­ike.com ) [Type – Agile Project Management / Agile Product Management / Agile Develo­pment]
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 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]
MoSCoW Technique
The Moscow method is a priori­tiz­ation technique used in manage­ment, business analysis, project manage­ment, and software develo­pment to reach a common unders­tanding with stakeh­olders on the importance they place on the delivery of each requir­ement; it is also known as MoSCoW priori­tiz­ation or MoSCoW analysis. [Type – Agile Projec­t/P­roduct Manage­ment]
Pair Progra­mming
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]
Pareto Chart
One of the core principles of Agile develo­pment 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 Manage­ment, Agile Product Manage­ment]
Payback Period
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]
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 Develo­pment Team collab­orate on the details of Product Backlog items. During Product Backlog refine­ment, items are reviewed and revised. [Type – Agile Product Manage­ment]
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 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]
Product Owner
The Product Owner (PO) is a member of the Agile Team respon­sible for defining Stories and priori­tizing the Team Backlog to streamline the execution of program priorities while mainta­ining the conceptual and technical integrity of the Features or components for the team. [Type – Agile Product Manage­ment]
Program Increment
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]
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 diffic­ulty. [Type – Agile Estima­tion]
Retros­pective
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.
Release Train
The Agile Release Train (ART) is a long-lived team of Agile teams, which, along with other stakeh­olders, increm­entally develops, delivers, and where applicable operates, one or more solutions in a value stream. [Type – Agile Product Manage­ment]
Risk Based Technique
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]
Roadmap
A product roadmap is a plan of action for how a product or solution will evolve over time. When used in agile develo­pment, a roadmap provides crucial context for the team's everyday work and should be responsive to shifts in the compet­itive landscape. Multiple agile teams may share a single product roadmap. [Type – Agile Leader­ship]

Agile Develo­pment Terms & Termin­ologies [S-Z]

Satisf­action Histogram
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]
Scaled Agile Framework (SAFe)
The Scaled Agile Framework® (SAFe®) is a system for implem­enting Agile, Lean, and DevOps practices at scale. The Scaled Agile Framework is the most popular framework for leading enterp­rises because it works: it’s trusted, custom­izable, and sustai­nable. (Credits to www.sc­ale­dag­ile.com) [Type – Scaled Agile Framework / Large Scale Agile]
Schedule Variance
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]
Scrum
Scrum is a process framework used to manage product develo­pment and other knowledge work. [Type – Agile Project Management / Agile Develo­pment]
Scrum Master
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]
Scrum of Scrums
A technique to scale Scrum up to large groups (over a dozen people), consisting of dividing the groups into Agile teams of 5-10. [Type – Large Scale Agile / Scaled Agile Framework]
Spaghetti Diagram
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 Backlog
A sprint backlog is the subset of product backlog that a team targets to deliver during a sprint to accomplish the sprint goal and make progress toward a desired outcome. The sprint backlog consists of product backlog items that the team agreed with their product owner to include during sprint planning. The team owns the sprint backlog and can determine whether new items are added, or existing items are removed. This allows the team to focus on a clear scope for the length of the sprint. Some teams may allow the inclusion of a new product backlog item if it replaces a product backlog item of equal or greater size that already exists on the sprint backlog. [Type – Agile Projec­t/P­roduct Manage­ment]
Sprint Planning
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]
Sprints
In Agile product develo­pment, a sprint is a set period during which specific work has to be completed and made ready for review. Each sprint begins with a planning meeting. ... Tradit­ion­ally, a sprint lasts 30 days. After a sprint begins, the product owner must step back and let the team do their work. [Type – Agile Develo­pment]
Story
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]
Story Mapping
Story Mapping or User Story Mapping is a technique used in product discovery: outlining a new product or a new feature for an existing product. The result is a Story Map: all the user stories arranged in functional groups. This helps you keep your eye on the big picture while also providing all the details of the whole applic­ation. The main purpose of Story Mapping is to facilitate product discovery and priori­tiz­ation of develo­pment work. You achieve this by putting user activities and tasks on a map that serves to keep them in context. [Type – Agile Product Manage­ment]
Story Points
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]
Technical Product Owner
The technical product owner manages the technical aspects of the product develo­pment. Not all product owners are techni­cally sound and don’t have the necessary technical skills because a product owner is respon­sible for backlog management and maximizing product value. It isn’t necessary to have technical skills. A product owner needs a technical resource to deal with the techni­cal­ities of the develo­pment process. A technical product owner manages technical aspects of the develo­pment process. (Credits To https:­//p­rod­uct­man­age­rhq.com/) [Type – Agile Product Manage­ment]
Technical Spike
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.
Test Driven Develo­pment
“Test-driven develo­pment” refers to a style of progra­mming in which three activities are tightly interw­oven: coding, testing (in the form of writing unit tests) and design (in the form of refact­oring). [Type – Agile Develo­pment]
Test First Develo­pment
It is a different name for Test Driven Develo­pment (Refer Above)
T-Shirt Sizing
Refer to Relative Sizing in Agile (Refer Sheet #3)
Velocity
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]
XP (Extreme Progra­mming)
Extreme Progra­mming (XP) is an agile software develo­pment framework that aims to produce higher quality software, and higher quality of life for the develo­pment team. XP is the most specific of the agile frameworks regarding approp­riate engine­ering practices for software develo­pment. [Type – Agile Develo­pment]

Agile Develo­pment - Management Software & Tools

Asana
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]
JIRA
Jira Software is an agile project management tool that supports any agile method­ology, be it scrum, kanban, or your own unique flavor. From agile boards, backlogs, roadmaps, reports, to integr­ations and add-ons you can plan, track, and manage all your agile software develo­pment projects from a single tool. The product name is a truncation of Gojira, the Japanese word for Godzilla. [Type – Agile Projec­t/P­roduct Manage­ment]
Mingle
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]
Trello
Trello is an amazing Scrum and Agile solution. It works like a tradit­ional whiteboard but in a digital form. The flexib­ility of Trello boards is perfectly aligned with the Scrum framework, as it gives you full visibility into project stages, roles, and deadlines. [Type – Agile Projec­t/P­roduct Manage­ment]
Yoco Board :-)
Track time spent on Asana tasks, monitor produc­tivity across multiple projects, and easily automate payroll calcul­ations. [Type – Agile Project Manage­ment]
Zoho Sprints
Zoho Sprints is a free online tool that is used for agile planning and tracking. It helps in creating effective user stories, scheduling agile meetings, using timesh­eets, and adding estimation points for tracking the work hours. The main purpose of Zoho Sprints is to bring agility to the project develo­pment lifecycle. Being agile is a project management method that helps in building an iterative process where teams can quickly react to changes. This is an approach that is entirely different from the tradit­ional waterfall model which is much more focused on testing only after the final product is built. [Type – Agile Projec­t/P­roduct Manage­ment]
Rally
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]
-
-
Reference Link 01
Reference Link 02
Reference Link 03
Reference Link 04
Reference Link 05
Reference Link 06
Reference Link 07
Reference Link 08
Reference Link 09
Reference Link 10

Apt Quotes - Agile Develo­pment

“Intel­ligence is the Ability to Adapt to Change.” ~ Stephen Hawking ~
“Learn from Yesterday, Live for Today, Hope for Tomorrow. The Important thing is Not to Stop Questi­oning.” ~ Albert Einstein ~
“To improve is to change; To be perfect is to change often.” ~ Winston Churchill ~
“I can't change the direction of the wind, but I can adjust my sails to always reach my destin­ation.” ~ Jimmy Dean ~
“Change is the law of life, and those who look only to the past and present are certain to miss the future” ~ John F. Kennedy ~
“You build on failure. You use it as a stepping stone. Close the door on the past. You don't try to forget the mistakes, but you don't dwell on it. You don't let it have any of your energy, or any of your time, or any of your space.” -Johnny Cash“Just take any step, whether small or large. And then another and repeat day after day. It may take months, maybe years, but the path to success will become clear”* ~ Aaron Ross ~
“You build on failure. You use it as a stepping stone. Close the door on the past. You don't try to forget the mistakes, but you don't dwell on it. You don't let it have any of your energy, or any of your time, or any of your space.” ~ Johnny Cash ~
“Change is not pleasent, But change is constant. One when we can change and grow, We'll see a world we never know." ~ Wisdom Of The Orange Woodpecker ~
"­Times change, people change, situations change, relati­onships change... the only thing constant is change." ~ Unknown ~
"Your success in life isn’t based on your ability to simply change. It is based on your ability to change faster than your compet­ition, customers, and busine­ss."­ ~ Mark Sanborn ~
           
 

Comments

No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          PivotalTracker Search Cheat Sheet
          ISTQB Test Automation Engineering Cheat Sheet