Scrum Glossary Flashcards
burn-down chart
a chart which shows the amount of work which is thought to remain in the backlog
burn-up chart
a chart which shows the amount of work has been completed
coherent/coherence
the quality of the relationship between certain Product Backlog items which may make them worthy of consideration as a whole
daily scrum
event that is a 15 min timed-boxed event held each day for developers
definition of done
formal description of the state of the increment when it meets the quality measures required for the product
developer
any member of the scrum team that is creating any aspect of a usable increment each sprint regardless of technical, functional or other speciality
emergence
the process of 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: 1. transperancy 2. inspection 3. adaptation
engineering standards
a shared set of development and technology standards that developers apply to create releasable increments of software
forecast (of functionality)
the selection of items from the product backlog developers deems feasible for implementation in a sprint
increment
scrum artifact that defines the complete and valuable work produced by the developers during a sprint
the sum of all increments form a product
product backlog
a scrum artifact that consists of an ordered list of 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 developers add granularity to the product backlog
product owner
role in scrum accountable for maximizing the value of a product, particularly by incrementally managing and expressing business and functional expectations for a product to the developers
product goal
describes a future state of the product which can serve as the target for the scrum team to plan against.
the product goal is in the product backlog.
the rest of the product backlog emerges to define “what” will fulfill the product goal
ready
a shared understanding by the product owner and the developers regarding the preferred level of description of product backlog items introducted at the sprint planning
scrum
a lightweight framework that helps people, teams, and organization generate value through adaptive solutions for complex problems as definted in the scrum guide
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 master
role within the 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 managing team consisting of one scrum master, a product owner and developers
sprint
scrum event that is time-boxed to one month or less, that serves as a container for the other scrum events and activities.
sprints are done consecutively, without intermediate gaps
sprint backlog
scrum artifact that provides 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 developers
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
scrum event that is time-boxed to 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
topic one: why is this sprint valuable?
topic two: what can be done this sprint?
topic three: how will the chosen work get done?
sprint retrospective
scrum event that is set to a time-box 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 future sprints
sprint review
scrum event that is set to a time-boxed of 4 hours or less, to conclude the development work on 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 thew ork performed on overall progress toward the product goal 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
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 introducted purposefully to realize value earlier
value
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 “build trust” for everyone.
the scrum team members learnand explore those values as they work with the scrum events, roles, and artifacts.
velocity
an optional, but often used, indication of the amount of product backlog turned into an increment of product during a sprint by a scrum team, tracked by the developers for use within the scrum team
behavior-driver development (bdd)
agile software development practice adding to the test driven development (TDD) the description of the desired functional behavior of the new functionality
blameless postmortem
understand systemic factors that lead to an outage and identify learnings and actions that can help to prevent this kind of failure from recurring.
this practice is based on the idea that in hindsight we usually know how the outage could have been prevented
but the past cannot be changed and therefore it is NOT useful to discuss who should have done what, aka as blaming
but it is about shaping the future by learning from what just happened.
what can we learn and how can we improve our process to make it more resilient?
blue-green deployment
practice that helps reducing down-times while upgrading the system to a new version
it has other positive effects like fast rollbacks in case of emergency
it uses two identical environments
one environment (called blue to differentiate it from the other identical one) is handling all requests and executing all production operations
the other environment (green) can handle software updates and configuration changes without impacting production. even tests can be executed on green without risk
once green’s environment is ready, all requests are switched over to this one and it becomes the new blue.
the previous blue at the same time becomes the green one and can be used for the next update
branching
creating logical or physical copy of code within a version control system so that this copy might be changed in isolation
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 independencies between modules, while cohesion describes how related the functions within a single module are
collective code ownership
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 deliver
software delivery practices similar to continuous deployment except a human action is required to promote changes into a subsequent environment along the pipeline
continuous integration
agile software development practice popularized extreme programming in which newly checked-in code is built, integrated, and tested frequently, generally multiple times a day
continuous testing
traditional approaches of quality assurance are often based on getting all implementation finished before verifying the latest build of the product of integrating testing as a fundamental and ongoing part of development
helps to identify and fix issues much earlier and so lowers risk drastically
continuous testing is especially powerful if combined with practices like test automation,
clean code and others which help to reduce regression testing efforts
cycle time
is the time between working on an item that has been started and the item is finished (usually delivered to real end-users)
cycle time defines how fast work can flow through a system and minimizing cycle time helps not only to make the system more efficient but also to increase predictability and the ability to quickly respond to changes or new insights
cyclomatic complexity
a measure of code complexity based on the number of independent logical branches through a codecase
cyclomatic complexity is expressed as a simple integer
cross-functional
characteristic of a team holding that all the skills required to successfully product a releasable increment in a sprint are available within the team, where releasable refers to making the software available in production
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
dev & ops collaboration
is at the core of the DevOps movement
instead of separating development and operations, collaboration is key
instead of developing something and then making running this in production someone else’s problem, we try to achieve end-to-end responsibility
this not only helps with smoothening the delivery process, but it also closes the feedback loop
a closer collaboration strengthens learning how we could support robust operations already in the design and implementation operations, and vice versa
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 codebase
engineering standards
a shared set of development and technology standards that the developers apply to create releasable Increments of software, and against which those developers can inspect and adapt
error culture
how mistakes are handled has an important impact on organizations ability to innovate
if people feel that errors are something negative and try to avoid them, they might be much less likely to take a risk and try something new
instead encouragement for experimentation and learning is important while at the same time considering how to tame risks and decrease the impact of failures
extreme programming (xp)
agile software 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
feature flags / 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
hypothesis driven development
in a complex environment we do not know where to invest in order to achieve the highest possible value: we need to formulate a hypotheses about that
once we accept uncertainty and agree that the assumptions our plans are based on can be wrong, it makes sense to change our approach to the development of new features
validating our assumptions gets high priority and finding and fast experiments to get more insights become an important part of work
infrastructure as code
instead of setting up and configuring infrastructure and environments, this process can be automated by scripts and parameter files
while this approach is not faster for the initial setup of the infrastructure (it might even be slower), it provides a lot of advantages
the scripts and configuration files can be stored in a version control together with the source code of the software
this allows to created exactly the matching environment for a given version of the software
changes to the environment are documented in version control as they are no longer executed on the environment directly but by changing and executing a script
and new instances of an exact copy of the production environment can easily be created, for example, testing purposes
mean time to detect (mttd)
is the time it takes to identify that there is a problem
the MTTD should not be determined by the first call of an angry customers at the hotline
monitoring tools can help to reduce it
mean time to recover (mttr)
average time it takes for when a problem occurs until the problem is fixed and the system is back to normal operations
there are various techniques helping with mttr as defensive programming and self-healing systems that can switch to an emergency mode to keep the basic functionality of the system up and running
as mttd is usually a significant portion of mttr, reducing mttd will also with with mttr
minimum viable product
one practice to achieve hypothesis driven development is the minimum viable product (MVP)
the MVP is the smallest implementation of our product or a feature which allows to learn about how users will react to it or technical behavior like performance
monitoring
helpful to know what the current state of your system is
most systems support logging to analyze what happened during an outage or a problem, monitoring is used to change the current state continuously
once one or more parameters get out of a healthy range, alarms can be triggered to initiate some actions
pair programming
agile software development practice popularized by extreme programming in which two team members jointly create new functionality
refactoring
agile software development practice popularized by extreme programming in which code is adjusted within the codebase without impacting the external, functional behavior of that code
release-pipelines
automating the steps from code commit to version control to delivery in production help increasing speed and reliability of this process
this practice is often referred as release-pipelines as this pictures the ideal of a steady stream of changes delivered
scout rule
the practice of always leaving the codebase in a little better state than it was found before modifications
a means to progress towards clean code
self-managing
scrum teams are cross-functiona, meaning the members have all the skills necessary to create value each sprint
they are also self-managing they internally decide who does what, when, and how
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
test-automation / test-automating
test is not only a way to increased the quality of a product, it also helps to reduce cycle time
if you see test execution as one form of feedback, automated tests help to get this feedback mush earlier
this lowers the effort of fixing issues and allows to deliver releasable increments much faster