Agile: the name coined for the wider set of ideas that Scrum falls within; the Agile values and principles are captured in the Agile Manifesto.
Acceptance Criteria: Details that indicate the scope of a user story and help the team and product owner determine done-ness.
Architect: there is no architect role on a Scrum team, instead all team members are responsible for emerging the architecture.
ALM (Application Lifecycle Management): holistic view on the management of software applications and systems, accounting for all stages of the existence of a software product.
ATDD (Acceptance Test-Driven Development): test-first software development practice in which acceptance criteria for new functionality are created as automated tests. The failing tests are constructed to pass as development proceeds and acceptance criteria are met.
Burn-down Chart: a chart which shows the amount of work which is thought to remain in a backlog. Time is shown on the horizontal axis and work remaining on the vertical axis. As time progresses and items are drawn from the backlog and completed, a plot line showing work remaining may be expected to fall. The amount of work may be assessed in any of several ways such as user story points or task hours. Work remaining in Sprint Backlogs and Product Backlogs may be communicated by means of a burn-down chart. See also: Burnup Chart
Burn-up Chart: a chart which shows the amount of work which has been completed. Time is shown on the horizontal axis and work completed on the vertical axis. As time progresses and items are drawn from the backlog and completed, a plot line showing the work done may be expected to rise. The amount of work may be assessed in any of several ways such as user story points or task hours. The amount of work considered to be in-scope may also be plotted as a line; the burn-up can be expected to approach this line as work is completed.
Backlog Grooming :Backlog grooming is when the product owner and some, or all, of the rest of the team review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery.
Backlog Item: In Scrum, a product backlog item ("PBI", "backlog item", or "item") is a unit of work small enough to be completed by a team in one Sprint iteration. Backlog items are decomposed into one or more tasks.
BDD (Behavior-Driven Development): agile software development practice adding to TDD the description of the desired functional behavior of the new functionality.
Branching: creating a logical or physical copy of code within a version control system so that this copy might be changed in isolation.
Coherent/Coherence: The quality of the relationship between certain Product Backlog items which may make them worthy of consideration as a whole. See also: Sprint Goal.
Chicken (arch.) term for anyone not on the team, the term offended some people so is now rarely used, cf. Pig
Clean Code: software code that is expressed well, formatted correctly, and organized for later coders to understand. Clarity is preferred over cleverness.
Code Coverage: a measurement indicating the amount of product code that is exercised by tests.
Cohesion and Coupling: coupling refers to the interdependencies between modules, while cohesion describes how related the functions within a single module are.
Collective Code Ownership: a software development principle popularized by Extreme Programming holding that all contributors to a given codebase are jointly responsible for the code in its entirety.
Continuous Delivery: a software delivery practice similar to Continuous Deployment except a human action is required to promote changes into a subsequent environment along the pipeline.
Continuous Deployment: a software delivery practice in which the release process is fully automated in order to have changes promoted to the production environment with no human intervention.
Continuous Integration (CI): agile software development practice popularized by Extreme Programming in which newly checked-in code is built, integrated and tested frequently, generally multiple times a day.
Cyclomatic Complexity: a measure of code complexity based on the number of independent logical branches through a code base. Cyclomatic complexity is expressed as a simple integer.
Cross-functional: characteristic of a team holding that all the skills required to successfully produce a releasable Increment in a sprint are available within the team, where releasable refers to making the software available in production.
Daily Scrum: daily time-boxed event of 15 minutes, or less, for the Development Team to re-plan the next day of development work during a Sprint. Updates are reflected in the Sprint Backlog.
A fifteen-minute daily meeting for each team member to answer three questions:
The ScrumMaster ensures that participants call sidebar meetings for any discussions that go too far outside these constraints.
The Scrum literature recommends that this meeting take place first thing in the morning, as soon as all team members arrive.
Definition of Done: a shared understanding of expectations that the Increment must live up to in order to be releasable into production. Managed by the Development Team.
Development Team: the role within a Scrum Team accountable for managing, organizing and doing all development work required to create a releasable Increment of product every Sprint.
Done also referred to as "Done" or "Done Done", this term is used to describe a product increment that is considered potentially releasable; it means that all design, coding, testing and documentation have been completed and the increment is fully integrated into the system.
Definition of Done: a shared understanding of the expectations that software must live up to in order to be releasable into production, with a purpose of providing transparency over the software created. Managed by the Development Team.
Developer: any member of a Development Team, regardless of technical, functional or other specialty.
DevOps: an organizational concept serving to bridge the gap between development and operations, in terms of skills, mind-set, practices and silo-mentality. The underlying idea is that developers are aware of, and in daily work consider implications on operations, and vice versa.
Development Team: the self-organizing role within a Scrum Team accountable for managing, organizing and doing all work required to create a releasable Increment of product every Sprint. All work is called development.
DRY (don’t repeat yourself): software development principle to avoid repetition of the same information in one system, preventing the same code from being produced multiple times on a code base.
Emergence the principle that the best designs, and the best ways of working come about over time through doing the work, rather than being defined in advance, cf. Empiricism, Self Organization.
Empiricism the principle of "inspect and adapt" which allows teams or individuals to try something out and learn from the experience by conscious reflection and change, cf.
Emergence: Self Organization.
Epic a very large user story that is eventually broken down into smaller stories; epics are often used as placeholders for new ideas that have not been thought out fully. There's nothing wrong with having an epic, as long as it is not high priority.
Estimation the process of agreeing on a size measurement for the stories in a product backlog. Done by the team, usually using Planning Poker.
Emergence: the process of the coming into existence or prominence of new facts or new knowledge of a fact, or knowledge of a fact becoming visible unexpectedly.
Empiricism: process control type in which only the past is accepted as certain and in which decisions are based on observation, experience and experimentation. Empiricism has three pillars: transparency, inspection and adaptation.
Engineering standards: a shared set of development and technology standards that a Development Team applies to create releasable Increments of software.
Engineering Standards: a shared set of development and technology standards that a Development Team applies to create releasable Increments of software, and against which a Development Team can inspect and adapt.
Extreme Programming (XP): agile software development framework with an extreme focus on programming and taking engineering practices to an extreme in order to create and release high quality code. Highly complementary to the Scrum framework.
Forecast (of functionality): the selection of items from the Product Backlog a Development Team deems feasible for implementation in a Sprint.
Fibonacci Sequence the sequence of numbers where the next number is derived by adding together the previous two (1,2,3,5,8,13,20…) ; the sequence has the quality of each interval getting larger as the numbers increase; the sequence is often used for Story Points, simply because estimates are always less accurate when dealing with epics.
Feature Toggle: software development practice that allows dynamically turning (parts of) functionality on and off without impacting the overall accessibility of the system by its users.
How "the How" is a term used to describe the domain of the team, as distinct for the product owner, cf “What”.Can also be described as tactic (i.e. how to win the battle).
Increment: a piece of working software that adds to previously created Increments, where the sum of all Increments -as a whole - form a product.
Impediment anything that prevents the team from meeting their potential (e.g. chairs are uncomfortable). If organizational, it is the Scrum Master's responsibility to eliminate it. If it is internal to the team, then they themselves should do away with it.
Impediment Backlog a visible or nonvisible list of impediments in a priority order according to how seriously they are blocking the team from productivity.
Product Backlog refinement: the activity in a Sprint through which the Product Owner and the Development Teams add granularity to the Product Backlog.
Product Owner: the role in Scrum accountable for maximizing the value of a product, primarily by incrementally managing and expressing business and functional expectations for a product to the Development Team(s).
Pig (arch.) term for a team member, the term offended some people so is now rarely used, cf. “Chicken”.
Planning Poker a game used to apply estimates to stories; it uses the Delphi method of arriving at consensus.
Process simply the way someone works. Everyone has a process. It can be predefined, empiric or merely chaotic.
Product Backlog: The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements. While there are multiple inputs to the product backlog, it is the sole responsibility of the product owner to prioritize the product backlog. During a Sprint planning meeting, backlog items are moved from the product backlog into a sprint, based on the product owner's priorities.
Product Backlog Item any item that is one the backlog list, which will include user stories, epics and possibly technical stories to deal with technical debt, etc.
Product Owner person whom holds the vision for the product and is responsible for maintaining, prioritizing and updating the product backlog. In Scrum, the Product Owner has final authority representing the customer's interest in backlog prioritization and requirements questions.This person must be available to the team at any time, but especially during the sprint planning meeting and the sprint review meeting.
Challenges of being a product owner:
Pair Programming: agile software development practice popularized by Extreme Programming in which 2 team members jointly create new functionality.
Product Burndown Chart
In Scrum, the product burndown chart is a "big picture" view of a project's progress. It shows how much work was left to do at the beginning of each sprint. The scope of this chart spans releases; however, a release burndown chart is limited to a single release.
Ready: a shared understanding by the Product Owner and the Development Team regarding the preferred level of description of Product Backlog items introduced at Sprint Planning.
Refinement: see Product Backlog Refinement
Relative Estimation – sizing backlog items by grouping them into relative size ranges rather than by absolute units (e.g. – hours). See Fibonacci and t-shirt sizes.
Release The transition of an increment of potentially shippable product from the development team into routine use by customers. Releases typically happen when one or more sprints has resulted in the product having enough value to outweigh the cost to deploy it.
Release Burndown Chart a visible chart to show progress towards a release.
Retrospective a session where the Team and Scrum Master reflect on the process and make commitments to improve.
Roman Vote see Thumb Vote
Refactoring: agile software development practice popularized by Extreme Programming in which code is adjusted within the code base without impacting the external, functional behavior of that code.
Scrum: a framework to support teams in complex product development. Scrum consists of Scrum Teams and their associated roles, events, artifacts, and rules, as defined in the Scrum GuideTM.
Scrum Board: a physical board to visualize information for and by the Scrum Team, often used to manage Sprint Backlog. Scrum boards are an optional implementation within Scrum to make information visible.
Scrum Guide™: the definition of Scrum, written and provided by Ken Schwaber and Jeff Sutherland, co-creators of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together.
Scrum Master: the role within a Scrum Team accountable for guiding, coaching, teaching and assisting a Scrum Team and its environments in a proper understanding and use of Scrum.
Scrum Team: a self-organizing team consisting of a Product Owner, Development Team and Scrum Master.
Scrum Values: a set of fundamental values and qualities underpinning the Scrum framework; commitment, focus, openness, respect and courage.
Self-organization: the management principle that teams autonomously organize their work. Self-organization happens within boundaries and against given goals. Teams choose how best to accomplish their work, rather than being directed by others outside the team.
Sprint: time-boxed event of 30 days, or less, that serves as a container for the other Scrum events and activities. Sprints are done consecutively, without intermediate gaps.
Sprint Backlog: an overview of the development work to realize a Sprint’s goal, typically a forecast of functionality and the work needed to deliver that functionality. Managed by the Development Team.
Sprint Goal: a short expression of the purpose of a Sprint, often a business problem that is addressed. Functionality might be adjusted during the Sprint in order to achieve the Sprint Goal.
Sprint Planning: time-boxed event of 8 hours, or less, to start a Sprint. It serves for the Scrum Team to inspect the work from the Product Backlog that’s most valuable to be done next and design that work into Sprint backlog.
Sprint Retrospective: time-boxed event of 3 hours, or less, to end a Sprint. It serves for the Scrum Team to inspect the past Sprint and plan for improvements to be enacted during the next Sprint.
Sprint Review: time-boxed event of 4 hours, or less, to conclude the development work of a Sprint. It serves for the Scrum Team and the stakeholders to inspect the Increment of product resulting from the Sprint, assess the impact of the work performed on overall progress and update the Product backlog in order to maximize the value of the next period.
Stakeholder: a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review.
ScrumMaster Role TheScrumMaster is a facilitator for the team and product owner. Rather than manage the team, the ScrumMaster works to assist both the team and product owner in the following ways:
Source: Agile Project Management with Scrum, Ken Schwaber
Scrum Meetings Story Time, Planning, Review, Retrospective, Daily Scrum
Scrum Roles there are only three: product owner, Scrum Master, team member
Self Organization the principle that those closest to the work best know how to do the work, so set clear goals and boundaries and let them make all tactical and implementation decisions, cf. Emergence, Empiricism
Spike a short, time-boxed piece of research, usually technical, on a single story that is intended to provide just enough information that the team can estimate the size of the story
Sprint a time boxed iteration
Sprint Backlog Defines the work for a sprint, represented by the set of tasks that must be completed to realize the sprint's goals, and selected set of product backlog items.
Sprint Burndown a visible chart that indicates on a daily basis the amount of work remaining in the sprint.
Sprint Goal aka Sprint Theme, the key focus of the work for a single sprint.
Sprint Planning a meeting between the Team and the Product Owner to plan the sprint and arrive at an agreement on the commitment.
Sprint Task a single small item of work that helps one particular story reach completion.
Story a backlog item usually using the template form: as a [user] I want [function] so that [business value], cf Product Backlog Item.
Stakeholder Sometimes the following terms are used synonymously – although it should be noted that there are nuances in their definitions: story, user story, technical user story, product backlog item, PBI, and product requirement.
Story Point a unit of measurement applied to the size of a story, cf. Fibonacci Sequence T-shirt sizes, powers of 2, are other ways of assigning Story Points.
Story Time the regular work session where items on the backlog are discussed, refined and estimated and the backlog is trimmed and prioritized.
Scout Rule: the practice of always leaving the code base in a little better state than it was found before modifications. A means to progress towards Clean Code.
Self-organization: the organizational principle that teams autonomously organize their work. Teams choose how best to accomplish their work, rather than being directed by others outside the team. Self-organization happens within boundaries and toward goals.
Specification by Example: agile software development practice based on TDD and ATDD that calls for using realistic examples from past experience instead of untested or abstract statements in the description of the desired functional behavior.
Task see Sprint Task
Task List the tasks needed to complete the set of stories committed to a sprint.
Taskboarda wall chart with cards and sticky notes that represent all the work of a team in a given sprint; the task notes are moved across the board to show progress.
Team A team (or "Scrum development team") is optimally comprised of seven plus or minus two people and responsible for committing to work, delivering and driving the product forward from a tactical perspective.
For software development projects, the team members are usually a mix of software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc. This is often called "cross-functional project teams". Agile practices also encourage cross-functional team members.
During a sprint, the team self-organizes to meet the sprint goals. The team has autonomy to choose how to best meet the goals, and is held responsible for them. The ScrumMaster acts as a guardian to ensure that the team is insulated from the product owner. Scrum also advocates putting the entire team in one team room.
Team Member a team member is defined as anyone working on sprint tasks toward the sprint goal. In Scrum parlance, the PO and SM could also be Team Members, if they are developing.
Thumb Vote a quick pulse to get a sense of where the team are in terms of commitment, or agreement on a decision, etc. thumb up generally means agree, yes, or good, and thumb down disagree, no or bad; the analog version of this allows the thumb to be anywhere on the half circle to indicate differing degrees of agreeability.
Timeboxing setting a duration for every activity and having it last exactly that (i.e. neither meetings nor sprint are ever lengthened - ever).
TDD (Test-Driven Development): test-first software development practice in which test cases are defined and created first, and subsequently executable code is created to make the test pass. The failing tests are constructed to pass as development proceeds and tests succeed.
Technical Debt: the typically unpredictable overhead of maintaining the product, often caused by less than ideal design decisions, contributing to the total cost of ownership. May exist unintentionally in the Increment or introduced purposefully to realize value earlier.
User Story: agile software development practice from Extreme Programming to express requirements from an end user perspective, emphasising verbal communication. In Scrum, it is often used to express functional items on the Product Backlog.
Unit Test: low-level technical test focusing on small parts of a software system that can be executed fast and in isolation. The definition and boundaries of a ‘unit’ generally depends on the context and is to be agreed by the Development Team.
Values: When the values of Commitment, Courage, Focus, Openness and Respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and builds trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.
Velocity the rate at which a team completes work, usually measured in story points. In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning.
Once established, velocity can be used to plan projects and forecast release and product completion dates.
How can velocity computations be meaningful when backlog item estimates are intentionally rough? The law of large numbers tends to average out the roughness of the estimates.
Vision Statement a high-level description of a product which includes who it is for, why it is necessary and what differentiates it from similar products.
What "the What" is a term used to describe the domain of the product owner, as distinct for the team, cf. How. Can also be described as strategy (i.e. what's the best order for battles).
XP Practices the set of development practices, including pair-programming, test-first, or test-driven development (TDD) and continuous refactoring, which are drawn from the XP methodology; many Scrum teams find these practices greatly improve productivity and team morale.