This glossary is extremely useful when learning to your Scrum.org PSD certificate. Definitions are similar to what can be found on the internet, but we also tried to keep it simple stupid.
A
ALM (Application Lifecycle Management): management of software applications and systems, during all stages of the existence of a software product, from the idea, through development to maturity (or even death) of a product.
ATDD (Acceptance Test-Driven Development): similar to TDD, test-first software development practice. After creating a user story with acceptance criteria, we start development by writing down tests that match them. Tests are failing at the beginning and later they started to pass as development proceeds and acceptance criteria are met.
B
Burn-down Chart: a simple chart showing remaining effort against time.
Burn-up Chart: a chart showing the evolution of an increase in a measure against time.
BDD (Behavior-Driven Development): yet another technique based on TDD. Simply add to tests description of the desired functional behavior of the new functionality.
Branching: usually within a version control system – creating a copy of existing code, making changes on the copy and later decide if you want to replace origin (merge it) or not.
C
Clean Code: most importantly – The clean code is better than clever code. That said clean code is a software code that is:
- formatted correctly,
- easy to understand,
- well described with either comments or even better – good naming.
Code Coverage: a metric (measurement) indicating the amount (usually percentage) of product code that is exercised by tests. During development, it is best practice to keep this metric above some level.
Collective Code Ownership: in simple words – it means that all developers who contribute to the product are responsible for its code, not only the one who wrote the particular part.
Continuous Delivery: it’s a Continuous Deployment without automatization. So there will be manual work somewhere in the process.
Continuous Deployment: a software delivery practice in which the release process is fully automated (so there is no need for manual work). By release process we mean – putting the code to the production environment.
Continuous Integration (CI): ideally it is Continuous Deployment of ALL the changes that are made in the code.
Cyclomatic Complexity: a measure (metric) of code complexity. To calculate it count all independent logical branches in a code. Cyclomatic complexity is expressed as a simple integer. The lower the better.
Cross-functional: characteristic of a team. That means they have all the skills needed to deliver the product.
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. If they came up with an idea or suggestions – they should update Sprint Backlog.
Definition of Done: a usually written document describing what all people mean when they use word “Done”. Managed by the Development Team.
Definition of Ready: a usually written document describing what all people mean when they use the word “Ready for Development”. Managed by the Development Team.
Developer: any member of a Development Team, no matter if his or her role is Team Leader, Frontend or Backend, QA or Junior assistant – they all are developers.
DevOps: layer between Development and Infrastructure. DevOps in most companies are tech guys who don’t actively code but release to production delivered code. They might take care of CI, CD and some metrics.
Development Team: the self-organizing role within a Scrum Team. They are accountable for creating a releasable Increment of product every Sprint.
DRY (don’t repeat yourself): on of software development principles. In simple words – if you are going to make copy-paste of your code from one place to another within one project – refactor the code instead.
E
Empiricism: only certain things are past. The future is unknown, but we can predict the future based on past experiments. Empiricism has three pillars: transparency, inspection, and adaptation.
Extreme Programming (XP): agile software development framework with a focus on programming. It is not within Scrum but complementary to Scrum. It covers such ideas as Pair Programming, Code Review, and others.
F
Feature Toggle: software development practice. It is an approach of creating a switch in code, so that part of the software can be turned off and on without releasing new versions. Helpful when testing.
Forecast (of functionality): part of Product Backlog Items, which Development Team commit to deliver to end of the Sprint.
I
Increment: a piece of working software. All increments together create a Product.
P
Pair Programming: practice popularized by Extreme Programming. In that practice 2 team members together create new functionality (commonly using only 1 keyboard).
Product Backlog: an ordered list of PBI’s. Managed by the Product Owner.
Product Backlog Item: (PBI) part of work that needs to be done in order to create, maintain and sustain a product.
Product Backlog refinement: activity in a Sprint (up to 10%) when Product Owner and the Development Team refine existing or add or delete PBI’s.
Product Owner: the role in Scrum. This role is accountable for maximizing the value of a product.
R
Refactoring: improving the code without changing functionalities. Popularized by Extreme Programming.
S
Scout Rule: this is a rule to always leave code in better shape than when you opened it.
Scrum: a framework to support teams in complex product development.
Scrum Board: usually it is a Kanban board with columns such as TODO, IN PROGRESS, DONE and lots of in-between. Such a board is useful for visualizing progress towards the Sprint.
Scrum Guide: the definition of Scrum, written and provided by Ken Schwaber and Jeff Sutherland. There are definitions of roles (Scrum Master, Product Owner, and Development Team), values, artifacts and events written there.
Scrum Master: the role in a Scrum Team. SM is responsible for removing impediments and coaching the rest of the Scrum Team and even organization.
Scrum Team: a team of a Product Owner, Scrum Master, and Development Team.
Scrum Values (FROCC): a set of fundamental values. There are 5 values in Scrum: focus, respect, openness, commitment, and courage.
Self-organization: self-organized team knows exactly who should do what and why.
Sprint: time-boxed event of a maximum of 30 days. In the end Increment should be delivered.
Sprint Backlog: a subset of Product Backlog. Part of it that the Development Team committed to delivering in a Sprint.
Sprint Goal: the reason why the team is doing whole the work in the Sprint. A short expression of what they are trying to achieve in a Sprint.
Sprint Planning: event of a maximum of 8 hours, when the Scrum team composes Sprint Backlog and Sprint Goal.
Sprint Retrospective: time-boxed event of maximum 3 hours when Scrum Team to inspects the past Sprint and seek for improvements.
Sprint Review: event at the end of the Sprint. Maximum for 4 hours, when Scrum Team with the stakeholders inspect Increment and think about the future.
Stakeholder: someone not from the Scrum Team who has an interest in product success.
T
TDD (Test-Driven Development): approach in which we start development by writing down tests that check requirements. Tests are failing at the beginning and later they started to pass as development proceeds.
Technical Debt: costs of maintaining the product. Usually, refinement of wrongly written class, obsolete library or lack of tests is good examples of technical debt.
U
User Story: descriptive sentence, explaining why the PBI is needed. Should answer the question:
- Who needs a feature?
- What feature does he need?
- Why he need that?
Unit Test: a low-level technical test of a small part of a code. Usually one or few Unit Tests are testing one method or function.
V
Velocity: speed of the Development Team. Measured value, helping the team to estimate their ability to deliver a feature in the deadline.