Agile Resources
What is Scrum?
Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs. Management and teams are able to get their hands around the requirements and technologies, never let go, and deliver working software, incrementally and empirically.
Scrum itself is a simple framework for effective team collaboration on complex software projects. Ken Schwaber and Jeff Sutherland have written The Scrum Guide to explain Scrum clearly and succinctly.
Below are a few terms you should be familiar with, when studying Scrum.
A
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.
B
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.
Burn-down Chart: a chart showing the evolution of remaining effort against time. Burn-down charts are an optional implementation within Scrum to make progress transparent.
Burn-up Chart: a chart showing the evolution of an increase in a measure against time. Burn-up charts are an optional implementation within Scrum to make progress transparent.
C
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.
D
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.
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.
E
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, 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.
F
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.
Forecast (of functionality): the selection of items from the Product Backlog a Development Team deems feasible for implementation in a Sprint.
I
Increment: a fully functional piece of working software, living up to the definition of Done, that adds to previously created Increments, where the sum of all Increments - as a whole - form a product. An Increment typically is the result of a Sprint.
P
Pair Programming: agile software development practice popularized by Extreme Programming in which 2 team members jointly create new functionality.
Product Backlog: an ordered list of the work to be done in order to create, maintain and sustain a product. Managed by the Product Owner.
Product Backlog refinement: the activity in a Sprint through which the Product Owner and the Development Team 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).
R
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.
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.
S
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.
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 Guide™.
Scrum Board: a board to visualize information within the Scrum Team primarily, often used to manage Sprint Backlog. Scrum boards are an optional implementation within Scrum to make information visible and thereby increase transparency.
Scrum Guide™: the definition of Scrum, written and provided by Ken Schwaber and Jeff Sutherland, co-creators of Scrum. The Scrum Guide 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 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.
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.
T
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 cost of having to resolve or work with unfinished, unclean, undone or defect code once it has been released into production.
U
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.
V
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: an optional but often used indication of the average amount of Product Backlog turned into an Increment of product during a Sprint. It is tracked by the Development Team for use within the Scrum Team.