Mindset is a reflection of our assumptions, biases, way of thinking, and beliefs that is visible in our choices, decisions and behavior. An Agile mindset characterizes flexibility and willingness to adapt to changes and unforeseen circumstances. A person / team having an Agile mindset is: Curious to learn, Continuously trying to improve, Willing to experiment new ideas, Not hesitant to take risks, Not running away from challenges, like growing a muscle, so that when needs / circumstances change, they are ready to adapt to it. An Agile Mindset underpins the work of successful agile teams. On the other hand, someone having a Fixed Mindset would be relatively less flexible, thinks that they know it all, assumes there will be no changes, is not open to learning / feedback, avoid trying new ideas etc. 'Mindset' by Carol Dweck introduced a comparision between a Growth Mindset and a Fixed Mindset and how one can inculcate a Growth Mindset. Also Refer: Agile Mindset by Kamlesh Ravlani

The Manifesto for Agile Software Development Established in 2011, also referred as Agile Manifesto comprises of four Values and twelve Principles that 17 manifesto authors agreed on to be essential to be adaptable for a team or an organization. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Principles behind the Agile Manifesto We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Manifesto Authors: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas Refer: Manifesto for Agile Software Development

Scrum is a light weight framework that helps people generate value through adaptive solutions for complex problems. Scrum Framework is built on empiricism and lean thinking. Scrum employs an iterative, incremental approach to optimize predictability and to control risk. As a framework, Scrum is not prescriptive, but only offers few elements and the rules associated with these elements. Further Reading: A short summary of the Scrum Framework

The Scrum Master is responsible for promoting and supporting Scrum. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values. Scrum Master is not a new name for the traditional (Project) Manager. Rather, the Scrum Master is a true leader who leads through serving. The Scrum Master Educates, Coaches, Mentors and Facilitates to higher performance and agility. The Scrum Master serves the Developers, the Product Owner and the Organization. Also see: Scrum Masterr as a Coach , Scrum Master as a Leader

Lean thinking is an organizational approach, based on the view that non-value-added activities (waste) in products and services impedes customer value creation. It focuses on ways to organize human activities to effectively deliver value while reducing muda (waste), mura (unevenness) and muri (overburden). Lean Thinking ideas emerged from studying Toyota Production System (TPS). It was found that if every employee is trained to identify wasted effort, steps and time in their own work and to work together as a team to improve processes by eliminating such waste, the resulting culture (basic thinking, mindset & assumptions) will deliver more value effectively while improving team work, their capability, and motivation. Also see: Lean Waste , Lean Product Development , Kaizen , PDCA

Acceptance criteria (AC) is the set of criteria that define / limit the functional scope of a Product Backlog Item. It guides how a particular feature may be used from an end user’s perspective. If the implementation of a functionality meets the Acceptance Criteria the Product Backlog Item (PBI) or a User Story would be accepted by the user, the customer, or the Product Owner. Acceptance critieria for each PBI would be different and unique as it relates to the functional scope of that PBI. Acceptance criteria is different from Definition of Done which focuses on Quality and Completeness. DoD is common across the PBIs and is consistent for the Product. Refer for More: Tips to Write Effective Acceptance Criteria

The Definition of Done (DoD) is a set of criteria for quality and completeness of the increment, against which the increment is evaluated. DoD creates transparency and shared understanding of what work was completed as part of the Increment. The Definition of Done is common across Product Backlog Items and consistent for a Product. The DoD is established before the work begins and is expanded (as needed) over the period. The Definition of Done is different from the Acceptance Criteria (AC). The AC is focused on functional scope of one PBI where as the DoD is focused on quality scope of the entire product. See also : Increment , Acceptance Criteria

Empiricism asserts that knowledge comes from experience and making decisions based on what is observed (Most recent, Factual, Information). Scrum is founded on the three pillars of Empiricism: Transparency, Inspection and Adaptation. Transparency : Scrum artifacts create transparency of needed information. Transparency enables Inspection. Inspection without transparency is misleading and wasteful. Inspection : Four formal Scrum events enable opportunities for inspection and adaptation. Inspection of the information enables to know if the actual resutls match or deviate from the desired results. Adaptation : Four formal Scrum events enable opportunities for inspection and adaptation. If during the inspection, the actual resutls is found to deviate from the desired results, we can adapt the input, so the desired results can be achieved.

A burn down chart is a graphical representation of the work left to do versus the time. If a burn down chart is created at for a two week Sprint having 8 Product Backlog Items (work) in the Sprint Backlog, the X-Axis will have 0 - 10 days and the Y-Axis will show 0 - 8 PBIs. As the days pass and the work remaining reduces, the graph from the top left will gradually trend (burn) down towards bottom right. The developers may (choose to) create and update the Sprint burn-down chart to graphically track the progress during the sprint. The Scrum Master should neither create, nor update the Burn-Down chart, to ensure that the Developers retain the ownership of tracking and monitoring the progress of their Sprint work. Also see: Burn Up Chart , Cumulative Flow Diagram (CFD)

A Burn Up Chart is a graphical representation used to track how much work has been completed against the time passed. The graph starts at 0-0 at the beginning of the Sprint and will tend (Burn) up towards Right as the days pass and top as the work is completed. A Burn Down Chart is a more effective tracking approach compared to the Burn Up Chart. Also see: Burn Down Chart , Comulative Flow Diagram (CFD)

The increment is the sum of all the Product Backlog items completed during a Sprint and the increments from previous Sprint. Increment creates transparency of the value created to date. Example: If a Scrum team is writing a book, a chapter of the book could be an increment. Another example could be iPhone 14 as an increment. Also see: Incremental Development

Sprint Planning is one of the prescribed Events within the Scrum framework. Conducted at the beginning of every Sprint where the work to be performed for the Sprint is planned. Sprint Planning addresses the Why, What, and How of the sprint work.

The Daily Scrum is a 15-minute time-boxed event for the Developers of the Scrum Team. During the Daily Scrum, the developers inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. It is held at the same time every working day of the Sprint. Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings. The Scrum Master and the Product Owner are not required (participants) at the Daily Scrum. While they can observe, they do not interrupt or interfere.

Sprint Review is the opportunity to inspect the increment (outcome of the sprint) and adapt the product backlog. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. Participants collaborate on what to do next. The Sprint Review is the second to last event of the Sprint.

Most popular - Agile and Scrum Glossary