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. adaptationengineering 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
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, emphasizing 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 tat can be executed fast and in isolation
the definition and boundaries of a unit generally depends on the context and is to be agreed upon by the developers
velocity
an optional but often used indication of the amount of Product Backlog turned into an Increment of product during a sprint
it is tracked by the developers for use within the scrum team
vertical teams
combines all the necessary competencies to handle the whole process from end-to-end
in such scenarios teams typically are only responsible for small parts of the whole product
so instead of splitting the organization into horizontal layers (departments) this approach suggests slicing the product
scrum requires a scrum master to foster an environment where
- a product owner orders the word for a complex problem into a product backlog
- the scrum team turns a selection of the work into an increment of value during a sprint
- the scrum team and its stakeholders inspect the results for the next sprint
- repeat
scrum is founded…
on empiricism and lean thinking
empiricism asserts that knowledge comes from experience and making decisions based on what is observed
lean thinking reduces waste and focuses on the essentials
empirical scrum pillars
transparency
inspection
adaptation
transparency
emergent process and work must be visible to those performing the work as well as those receiving the work
transparency enables inspection
inspection without transparency is misleading and wasteful
inspection
scrum artifacts and the progress toward agreed goals must be inspected frequently and diligence to detect intentionally undesirable variances or problems
inspection enables adaptation
inspection without adaptation is considered pointless
scrum events are designed to provoke change
adaptation
if any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted
the adjustment must be made as soon as possible to minimize further deviation
adaptation becomes more difficult when the people involved are not empowered or self-managing
scrum values (5)
commitment focus openness respect courage
developers are accountable for
1 creating a plan for the sprint, the sprint backlog
2 instilling quality by adhering to a definition of done
3 adapting their plan each day towards the sprint goal
4 holding each other accountable as professionals
product owner is accountable for…
effective product backlog management, which includes:
1 developing and explicitly communicating the product goal
2 creating and clearly communicating product backlog items
3 ordering product backlog items
4 ensuring that the product backlog is transparent, visible, and understood
scrum master serves the product owner in several ways…
1 helping find techniques for effective product goal definition and product backlog management
2 helping the scrum team understand the need for clear and concise product backlog items
3 helping establish empirical product planning for a complex environment
4 facilitating stakeholder collaboration as requested or needed
during the sprint
1 no changes are made that would endanger the sprint goal
2 quality does not decrease
3 the product backlog is refined as needed
4 scope may be clarified and renegotiated with the product owner as more is learned
scrum artifacts
represent work or value
product backlog it is the product goal
sprint backlog it is the sprint goal
increment is the definition of done
all development teams working on the same product should use the sam product backlog (true or false)
true
multiple teams often work together on the same product
one product backlog is used to describe the upcoming work on the product
who has the authority to cancel the sprint? 1 scrum master 2 product owner 3 development team 4 the key stakeholders 5 the product owner and the scrum master
2 the product owner
only the product owner has the authority to cancel the sprint, although he or she may do so under the influence from the stakeholders, the development team, or the scrum master
who is the leader in terms of getting feedback from the key stakeholders in the sprint review 1 scrum team 2 scrum master 3 development team 4 product owner
4 product owner
the product owner is a vital leader in terms of getting feedback from the key stakeholders in the sprint review
when is the scrum team allowed to interact with the key stakeholders (select the most appropriate option)?
1 sprint retrospective
2 daily scrum
3 any time where its valuable to have the stakeholder input
4 the sprint review
3 any time where it’s valuable to have the stakeholder input
the product owner is responsible for making sure that the key stakeholders attend and interact in the sprint reviews, but really the stakeholders can be involved with the scrum team any time where its valuable to have the stakeholder input
select the two focus areas that are NOT considered in executing value-driven development by the product owner
1 remover of impediments to the development team’s progress
2 product release decision maker
3 product marketplace expert
4 product visionary
5 lead facilitators of key stakeholder involvement
6 product value maximize
7 coach the development team in self-organization and cross-functionality
1 remover of impediments to the development team’s progress
7 coach the development team in self-organization and cross-functionality
what is the essence of scrum? select the most appropriate option
1 a small team of people that is highly flexible and adaptive
2 scrum master and product owner
3 development team
4 scrum guide
1 a small team of people that is highly flexible and adaptive
the essence of scrum is a small team of people
the individual team is highly flexible and adaptive
these strengths continue operating in single, several, many, and networks of teams that develop, release, operate and sustain the work and work products of thousands of people
they collaborate and interoperate through sophisticated development architectures and target release environments
who has the last say on the order of items in the product backlog? 1 scrum master 2 product owner 3 development team 4 product owner and the scrum master
2 product owner
while the product owner is not the only person who may influence the ordering of the product backlog, the product owner has the “last say” on the order of the product backlog, and those wanting to change the order of the product backlog have to influence the product owner to do so
the scrum team consists of 1 scrum master 2 product owner 3 development team 4 key stakeholders
1, 2, and 3
what is the order of items in the product backlog?
1 recently added items at the top
2 less valuable and most unclear items at the bottom
3 alphabetical
4 the less clear items at the top
2 less valuable and most unclear items at the bottom
the product owner is responsible for placing the most valuable and clear items at the top of the product backlog
scrum theory: where can scrum be used?
1 development of almost everything we use in our daily lives as individuals and societies
2 research and identify of viable markets, technologies, and product capabilities
3 development and sustaining of cloud and other operational environments
4 development of software and hardware
5 development of products and enhancements
6 managing the operation of an organization
1 development of almost everything we use in our daily lives as individuals and societies
2 research and identification of viable markets, technologies, and product capabilities
3 development and sustaining of cloud and other operational environments
4 development of software and hardware
5 development of products and enhancements
6 managing the operation of an organization
Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations, and almost everything we use in our daily lives, as individuals and societies.
Scrum has been used extensively, worldwide, to:
Research and identify viable markets, technologies, and product capabilities;
Develop products and enhancements;
Release products and enhancements, as frequently as many times per day;
Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use; and,
Sustain and renew products.
Imagine the following situation. At the Sprint Retrospective meeting, the Scrum Team identified some improvements that can be done. What should the Scrum Team do?
1 Make sure the Sprint Backlog for the next Sprint includes at least one high-priority process improvement.
2 Make sure the Sprint Backlog for the next Sprint includes all the improvements.
3 Assign responsible team members for every improvement. Check the progress at the next Retrospective.
4 Assign a responsible team member for at least one improvement. Check the progress at the next Retrospective.
1 Make sure the Sprint Backlog for the next Sprint includes at least one high-priority process improvement
The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high-priority process improvement identified in the previous Retrospective meeting.
Select the two meetings in which people outside the Scrum Team are allowed to participate.
1 The Daily Scrum
2 The Sprint Retrospective
3 The Sprint Review
4 The Sprint Planning
3 The Sprint Review
4 The Sprint Planning
The Development Team may invite other people to attend the Sprint Planning in order to provide technical or domain advice.
The Product Owner is responsible for inviting the Key Stakeholders to the Sprint Review meeting
How does the Scrum Master help the Product Owner? Select the three most appropriate answers.
1 Leading and coaching the organization in its Scrum adoption
2 Understanding product planning in an empirical environment
3 Facilitating Scrum events as requested or needed
4 Finding techniques for effective Product Backlog management
5 Introducing cutting edge development practices
2 Understanding product planning in an empirical environment
3 Facilitating Scrum events as requested or needed
4 Finding techniques for effective Product Backlog management
The Scrum Master serves the Product Owner in several ways, including:
Ensuring that goal, scope, and product domain are understood by everyone on the Scrum Team as well as possible;
Finding techniques for effective Product Backlog management;
Helping the Scrum Team understand the need for clear and concise Product Backlog items;
Understanding product planning in an empirical environment;
Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
Understanding and practicing agility; and,
Facilitating Scrum events as requested or needed.
How frequently the Product Owner should communicate and re-iterate his product vision to the Scrum Team and the Key Stakeholders?
1 Every Daily Scrum
2 Once at the first Sprint Planning
3 Every Sprint Retrospective
4 Early and often
4 early and often
The PO should communicate and re-iterate his product vision to the Scrum Team and the Key Stakeholders early and often, reminding all involved of how that vision aims to maximize the value of the product and of the work the Scrum Team performs.
Who is responsible for promoting and supporting Scrum? Select the best choice.
1 The Scrum Team 2 The Scrum Master and the Product Owner 3 The Product Owner 4 The Scrum Master 5 The Development Team
4 The Scrum Master
The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
What provides guidance to the Development Team on why it is building the Increment?
1 The Sprint Backlog
2 The Product Owner
3 The Scrum Master
4 The Sprint Goal
4 The Sprint Goal
The Sprint Goal is an objective set for the Sprint that can be met through the implementation of the Product Backlog. It provides guidance to the Development Team on why it is building the Increment.
When a product grows, it is quite possible that the PO will get help from other Product Managers and others in the organization who interact regarding the customer-facing activities and knowledge of the product marketplace. Is it a good idea for the PO to proxy or outsource some of their PO Scrum Team duties to these people (for example, Scrum Team facing duties)? (YES OR NO)
NO
When a product grows, it is quite possible that the PO will get help from other Product Managers and others in the organization who interact regarding the customer-facing activities and knowledge of the product marketplace. While it is fine for the PO to be aided by the aforementioned people, it is NOT acceptable for the PO to attempt to proxy or outsource their PO Scrum Team duties, especially the Scrum Team facing duties.
If multiple Stakeholders have varied interests in the product and different viewpoints what is the best strategy for the Product Owner?
1 Listen to the people that fund the product’s development because they always have the last word
2 Do an intelligent balancing of interests and try to maximize the value of the Product as a whole
3 Calculate ROI (Return Of Investments) for every viewpoint and select the maximal one
4 Stick to the viewpoint promising the fastest time-to-market
2 Do an intelligent balancing of interests and try to maximize the value of the Product as a whole
Inherent in the role of facilitating key stakeholder involvement is weighing and balancing the (likely) differing viewpoints of multiple stakeholders who might have varied interests in the product. The Product Owner’s responsibility is to maximize the value of the product as a whole, and this will involve an intelligent balancing of interests.
What are Product Backlog features? Select three.
1 It is never complete
2 When the final version of a product is rolled out, its Product Backlog is dismissed
3 It is dynamic
4 As long as a product exists, its Product Backlog also exists
5 A Product Backlog could be closed when it contains no items to include into the next Sprint
1 It is never complete
3 It is dynamic
4 As long as a product exists, its Product Backlog also exists
A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists.
Who is responsible for all estimates in the Product Backlog?
1 The Scrum Master and the Development Team
2 The Product owner and the Development Team
3 The Scrum Master
4 The Scrum Team
5 The Product owner and the Scrum Master
6 The Product Owner
7 The Development Team
7 The Development Team
The Development Team is responsible for all estimates in the Product Backlog. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.
How does the Product Owner communicate his marketplace knowledge to the Scrum Team (select three)?
1 Daily ad hoc interactions 2 Product Backlog Refinement 3 Sprint Retrospectives 4 Sprint Reviews 5 Daily Scrums
1 Daily ad hoc interactions
2 Product Backlog Refinement
4 Sprint Reviews
The Product Owner communicates all of this marketplace knowledge to the Scrum Team through daily ad hoc interactions as well as Product Backlog Refinement and in Sprint Reviews.
Product Backlog Refinement …
Select the three most applicable sentence endings.
1 Is an ongoing process
2 Usually takes no more than 10% of the capacity of the Development Team
3 Usually happens 2-4 times in dependency of the Sprint length
4 Answers the question: how will the work needed to deliver the Increment be achieved
5 Is time-boxed to a maximum of 4 hours
6 Is the act of adding detail, estimates, and order to Product Backlog items
1 Is an ongoing process
2 Usually takes no more than 10% of the capacity of the Development Team
6 Is the act of adding detail, estimates, and order to Product Backlog items
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. It usually consumes no more than 10% of the capacity of the Development Team.
What happens when a Sprint is canceled? Select three.
1 Any completed and “Done” Product Backlog items are reviewed
2 Several top Product Backlog Items are taken into the Sprint Backlog to replace the obsolete items
3 If part of the work is potentially releasable, the Product Owner typically accepts it
4 At the Sprint Retrospective the Scrum Master determines who from the Development Team is responsible for canceling the Sprint
5 All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog
1 Any completed and “Done” Product Backlog items are reviewed
3 If part of the work is potentially releasable, the Product Owner typically accepts it
5 All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog
When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog.
The Sprint Backlog is created at the Sprint Planning. It is prohibited to add new work into the Sprint Backlog later by the Development Team.
True
False
False
The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal. As new work is required, the Development Team adds it to the Sprint Backlog.
Who participates in the Sprint Review? Select all applicable variants.
The Scrum Master The Development Team The Product Owner The Organization CEO The Key Stakeholders
The Scrum Master
The Development Team
The Product Owner
The Key Stakeholders
During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.
What does Cone of Uncertainty show?
Dependencies, start times and stop times for project tasks
How much work remains till the end of the Sprint
Hierarchy of tasks that comprise a project
How much is known about the Product over time
How much is known about the Product over time
The Cone of Uncertainty describes the evolution of the amount of uncertainty during a project.
What two attributes are optional for a Product Backlog Item?
Description Test descriptions that will prove PB Item completeness when "Done" Value Dependencies Order Estimate
Test descriptions that will prove PB Item completeness when “Done”
Dependencies
Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”.
How long should the Sprint Planning be?
Until all the Items in the Sprint Backlog are decomposed to units of one day or less
Not more than 4 hours
Not more than 10% of the capacity of the Development Team
Not more than 8 hours
Not more than 8 hours
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint.
There is no need to decompose all the Items in the Sprint Backlog. It can be done only for the first days of the Sprint.
Who is allowed to make changes in the Product Backlog? Select two options.
The Scrum Master Anyone The Key Stakeholders The Development Team, but with permission of the Product Owner The Product Owner
The Development Team, but with permission of the Product Owner
The Product Owner
The Product Owner is the sole person responsible for the Product Backlog. However, he or she can delegate some work related to product backlog management to the Development Team.
What does Product Backlog management include? Select three most applicable items.
Presenting Product Backlog items to the Key Stakeholders
Moving Product Backlog items into the Sprint Backlog
Ordering the items in the Product Backlog to best achieve goals and missions
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next
Optimizing the value of the work the Development Team performs
Ordering the items in the Product Backlog to best achieve goals and missions
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next
Optimizing the value of the work the Development Team performs
Product Backlog management includes:
Clearly expressing Product Backlog items;
Ordering the items in the Product Backlog to best achieve goals and missions;
Optimizing the value of the work the Development Team performs;
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
Ensuring the Development Team understands items in the Product Backlog to the level needed.
Which KVA categories should the Product Owner consider to measure and track the creation and delivery of value to the market place (select three)?
Time-to-Market Employee Satisfaction Current Value Ability to Innovate Risk Reduction Capability Building
Time-to-Market
Current Value
Ability to Innovate
According to the Evidence Based Management an Organization should focus on the following Key Value Areas (KVA) categories:
Current Value
Time-to-Market
Ability to Innovate
What could be a source of requirements for any changes to be made to the product?
The Product Backlog
The CEO of the Organization
The Key Stakeholders
The Product Backlog
The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.
What does the word “development” mean in the context of Scrum? Select the best option.
Complex work that can include all the suggested options and even more
Research and identifying of viable markets, technologies, and Product capabilities
Product development, its releasing and sustaining
Software and hardware development
Development of an operational environment for the Product
Complex work that can include all the suggested options and even more
When the words “develop” and “development” are used in the Scrum Guide, they refer to complex work including software and hardware development, development and releasing of products and enhancements, development and sustaining product operational environments, research and identification of viable markets and technologies, and even more.
What factors should be considered by the Product Owner in the release decision (select four)?
Does the Increment meet the Definition of “Done”?
The risk that the product’s value can get out of line with the marketplace
Can customers actually absorb the new release?
Approval of the Key Stakeholders
The costs and benefits of the upgrade
The amount of work remaining toward the Sprint Goal
The customers that will be constrained by the new release
The risk that the product’s value can get out of line with the marketplace
Can customers actually absorb the new release?
The costs and benefits of the upgrade
The customers that will be constrained by the new release
While Scrum doesn’t require a release to occur every Sprint, it should be noted that the more elapsed time that accumulates since the last release, the higher the risk that the product’s value will get out of line with the marketplace. Product Owners should keep this risk in the forefront of their mind.
Another factor in the release decision is whether your customers can actually absorb your frequent releases. Most customers approach this upgrade decision using a common sense method of weighing the costs and benefits of the upgrade(new increment). This is all the more reason to make sure that your releases are of the utmost value, and offer relatively low absorption costs. Regardless of the benefits and costs, some customers will still be constrained, so this constraint should be a consideration when deciding how often or whether to release.
The PO is the one and only person who can decide whether to release the latest increment of the product.
The Increment is “Done” by its definition.
Who are the typical Key Stakeholders (select three)?
The human people who actually use the product under development
The people responsible for paying to use the product
The people responsible for making the funding decisions for the product development effort
The people responsible for product marketing
The people responsible for product development
The human people who actually use the product under development
The people responsible for paying to use the product
The people responsible for making the funding decisions for the product development effort
According to the Scrum Glossary, a stakeholder is “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.”
Typically, they fall into one of three broad categories:
The Users – The human people who actually use the product under development
The External Customers – The people responsible for paying to use the product
The Internal Customers – The people responsible for making the funding decisions for the product development effort
When something about Scrum frustrates the Product Owner, the PO can delegate some responsibilities to the Scrum Master.
True
False
False
It is NOT acceptable for the PO to attempt to proxy or outsource their PO Scrum Team duties.
The Product Owner will work in concert with the Scrum Master to utilize Scrum correctly and advantageously, and try to never been seen as subverting or disrespecting the Scrum framework. When something about Scrum frustrates a Product Owner, she should consult the Scrum Master for ways to implement the Scrum framework in a way that is effective.
What is the Increment?
The sum of all the Product Backlog items completed during the Sprint
The sum of all the Product Backlog items completed during the Sprint and the value of the increments of all previous Sprints
All items in the Sprint Backlog that could be released regardless of whether the Product Owner decides to actually do it
All “Done” items in the Sprint Backlog
The sum of all the Product Backlog items completed during the Sprint and the value of the increments of all previous Sprints
The Increment is the sum of all the Product Backlog items completed during the Sprint and the value of the increments of all previous Sprints.
Who participates in the Sprint Planning? Select three.
The Team Manager The Scrum Master The Key Stakeholders The Product Owner The Development Tea
The Scrum Master
The Product Owner
The Development Team
The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.
What are the three most applicable characteristics of the Product Owner?
Product Marketplace Expert
Product Value Maximizer
Lead Scrum evangelist in the Organization
Lead Facilitator of Key Stakeholder Involvement
Facilitator of Scrum events
Product Value Maximizer
Lead Facilitator of Key Stakeholder Involvement
Product Marketplace Expert
Who should do the legwork of gathering the marketplace data for the Product Owner?
The Scrum Team and the Key Stakeholders
It does not matter who does the legwork
The Product Owner
The Scrum Team
It does not matter who does the legwork
The Product Owner may or may not be the one doing the legwork of gathering the marketplace data, but the PO should definitely be aware of said data/research.
Could the Product Owner and the Scrum Master be a part of the Development Team?
Yes
No
Yes. Scrum does not prohibit the Product Owner or the Scrum Master do development work. However, it is not the best practice because it could create a conflict of interest.
Who is allowed to participate in the Daily Scrum?
The Key Stakeholders
The Product Owner
The Scrum Master
The Development Team
The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.
Who is the chief product visionary?
The Chief Executive Officer (CEO)
The Scrum Master
The Chief Marketing Officer (CMO)
The Product Owner
The Product Owner
The Product Owner is the chief product visionary. The PO should be able to clearly articulate the product vision to the Scrum Team and key stakeholders, and how that vision aims to maximize the value of the product and of the work the Scrum Team performs.
The Product Owner wants to apply some non-functional requirements to the Product. What is the best way to proceed?
Create a new Item for every requirement in the Product Backlog
Non-functional requirements cannot be handled within the bounds of Scrum
Add the non-functional requirements to the DoD and check every Increment against these criteria
Find a way to convert non-functional requirements into Product features and act accordingly
Add the non-functional requirements to the DoD and check every Increment against these criteria
Non-functional requirements describe the qualities of the Product being developed. For example, the Product should be secure and extensible. The only way to meet such requirements is to have them as a part of the DoD and check every Increment against these criteria.
Who is responsible for the Product Backlog?
The Scrum Master
The Product Owner and The Development Team
The Scrum Master and The Development Team
The Product Owner
The Product Owner and The Scrum Master
The Development Team
The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
How can the Product Owner bring his product vision to life (select 3)?
Utilizing the underlying empirical product planning features of Scrum
Making the Scrum Master bring the vision to the Scrum Team and the Key Stakeholders
Via the Product Backlog and iterating towards that vision every Sprint
Asking for an approval of the Upper Management
Articulating the product vision to the Scrum Team and the Key Stakeholders early and often
Utilizing the underlying empirical product planning features of Scrum
Via the Product Backlog and iterating towards that vision every Sprint
Articulating the product vision to the Scrum Team and the Key Stakeholders early and often
The PO should communicate and re-iterate his product vision early and often, reminding all involved of how to help maximize value. Utilizing the underlying empirical product planning features of Scrum, the PO should also be ready to make strategic pivots for the product vision. This vision is brought to life in a more tactical way, via the Product Backlog and iterating towards that vision every Sprint.
What happens during the Sprint? Select three answers.
No changes are made that would endanger the Sprint Goal
Quality goals do not decrease
Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned
The Sprint Goal is changed frequently to reflect the status of the remaining work
Sprint scope is defined at the Sprint Planning and cannot be changed
During the Sprint:
No changes are made that would endanger the Sprint Goal;
Quality goals do not decrease; and,
Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
If an item in the Sprint Backlog cannot be finished by the end of the Sprint (it turned out there is a lot more work to do than was estimated), the Sprint is canceled.
False
True
False
The Sprint is canceled only in the case if the Sprint Goal became obsolete. If some work could not be done, the Sprint Backlog should be re-negotiated between the Product Owner and Development Team.
What are the time-boxes for the Sprint Review and the Sprint Retrospective?
4 hour time-box for each
4 and 3 hours respectively
3 and 4 hours respectively
3 hour time-box for each
4 and 3 hours respectively
The Sprint Review is at most a four-hour meeting for one-month Sprints.
The Sprint Retrospective is at most a three-hour meeting for one-month Sprints.
what technique should be used for representing Product Backlog items?
User Stories
Any technique, even a mix of several techniques
Scenarios
Use Cases
Acceptance Tests
Any technique, even a mix of several techniques
User stories are a fairly common technique for representing Product Backlog Items, but other techniques can be used instead. For instance, a team can use scenarios, use cases, acceptance tests, etc. The Product Backlog might even contain a heterogeneous mix of the above.
The Product Owner should work with the rest of the Scrum Team on choosing and optimizing the techniques used to represent Product Backlog Items.
Product Backlog Refinement practice focuses on Items for upcoming Sprints, not the current Sprint in progress. True or false?
True
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.
The Items in the current Sprint are no longer on the Product Backlog, because they are now on the Sprint Backlog.
However, it is certainly fine for the Product Owner to add detail and clarification to the current Sprint’s work as well.
Who is responsible for creation of the Definition of “Done”?
The Development Team
If the definition of “done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. If “done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “done” appropriate for the product. If there are multiple Scrum Teams working on the system or product release, the development teams on all of the Scrum Teams must mutually define the definition of “Done.”
Who is responsible for tracking the total work remaining in the Sprint Backlog to project the likelihood of achieving the Sprint Goal?
The Scrum Master The Development Team The Scrum Team The Product Owner and the Development Team The Product Owner
The Development Team
At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.
It is a good practice to have at least two Product Owners on big projects.
True or False
False
The Product Owner is one person, not a committee, but the Product Owner may represent the desires of a committee in the Product Backlog.
What are the Scrum Artifacts? Select all applicable items.
The Sprint Goal Increment The list of removed impediments Sprint Backlog Product Backlog
Increment
Sprint Backlog
Product Backlog
The Scrum artifacts are Product Backlog, Sprint Backlog and Increment.
How does the Definition of “Done” help the Scrum Team? Select the three most applicable items.
DoD helps to calculate the velocity of the Scrum Team
DoD is used to assess when work is complete on the product Increment
Guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning
DoD ensures artifact transparency
DoD helps in inspection and adaptation
DoD is used to assess when work is complete on the product Increment
Guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning
DoD ensures artifact transparency
What is the Sprint Backlog?
The Product Backlog items selected for this Sprint plus the plan for delivering them
What part of the capacity of the Development Team does Product Backlog refinement usually consume?
The Development Team is not authorized for Product Backlog refinement
Not more than 10%
Not more than 20%
Not more than 5%
Not more than 10%
Product Backlog refinement usually consumes no more than 10% of the capacity of the Development Team.
What are the characteristics of a Product Backlog Item that is “Ready” for selection in a Sprint Planning? Select three.
Can be implemented within one Sprint and tested in the next Sprint
Somewhere at the bottom of the Product Backlog
Well refined
Has less detail
Somewhere at the top of the Product Backlog
Can be “Done” within one Sprint
Well refined
Somewhere at the top of the Product Backlog
Can be “Done” within one Sprint
Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning.
Development Team is waiting for a specific software component that they need to integrate and use.
The component should be ready in a month.
The Backlog Items with highest priorities depend on this specific component.
What should the Product Owner do?
Nothing. The Product Backlog already has the most valuable items at the top. The Development Team cannot proceed further until the dependency is resolved.
Make sure the dependency is visible in the Product Backlog and the Development Team has enough independent Items for the next Sprint.
Remove the dependent Items from the Product Backlog and put them in a special wait list. When the dependency is resolved, the Items should be returned back.
Transfer the dependent Items to the Integration Team
Make sure the dependency is visible in the Product Backlog and the Development Team has enough independent Items for the next Sprint.
The Product Backlog should make the dependency visible to all the interested parties.
Usually Items with external dependencies are not considered “Ready” for selection at the Sprint Planning.
Development Teams should deliver an Increment of product functionality every Sprint.
Select the five Scrum Values.
Openness Commitment Agility Respect Self-organization Courage Effectiveness Focus
The Scrum Guide recognizes the following Scrum Values: commitment, courage, focus, openness and respect.
How long does the Product Backlog exists?
While at least one Development Team is working on it
While the Product exists
Till the final Product Release
Not more than 5 years
While the Product exists
The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists.
All the Scrum Teams working on the same product should have the same Sprint length.
True
False
False. Scrum does not require having aligned Sprints for multiple teams.
The Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.
False
True
True
At the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.
Who is responsible for managing the Product Backlog?
The Product Owner
The Key Stakeholders
The Scrum Master
The Development Team
The Product Owner is the sole person responsible for managing the Product Backlog.
Who is responsible for monitoring progress toward high-level goals?
The Product Owner and The Development Team
The Scrum Master and The Development Team
The Development Team
The Scrum Team
The Product Owner
The Scrum Master
The Product Owner tracks total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.
Who is allowed to tell the Development Team to work from a set of requirements?
The Product Owner The Scrum Master The Key Stakeholders Upper Management The Product Owner and the Scrum Master
The Product Owner
The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.
Who identifies the Key Stakeholders for the Product?
The Upper Management The Scrum Team The Product Owner The Scrum Master The Development Team
The Product Owner
In order to maximize value, the Product Owner should identify the Key Stakeholders for the Product, and involve them as necessary throughout the development effort.
Who is allowed to change the Sprint Backlog during the Sprint?
The Development Team The Product Owner The Development Team and the Product Owner The Scrum Master The Scrum Team
The Development Team
Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.
What does Burn-down Chart show?
How much work remains till the end of the Sprint
Hierarchy of tasks that comprise a project
The evolution of the amount of uncertainty during a project
Dependencies, start times and stop times for project tasks
How much work remains till the end of the Sprint
Burn-down chart shows the evolution of remaining effort against time.
Every Product Backlog Item should be created by the Product Owner personally and only then the Development Team can add details to it at the PO’s discretion.
False
True
False. The Product Owner is solely responsible and accountable for the decisions in the Product Backlog. However, the legwork of managing the Product Backlog might be fully delegated to the Development Team, so it is quite possible that the Product Owner might not ever create or write a User Story or Product Backlog Item.
In which meetings the Key Stakeholders are allowed to participate?
The Sprint Planning
The Sprint Retrospective
The Daily Scrum
The Sprint Review
The Sprint Review
The Key Stakeholders are allowed to participate only in the Sprint Review meeting. However, any member of the Scrum Team can interact with them any time.
Once the Product Owner gained his Product Vision and defined the tactics of bringing this vision to life, it is a bad idea to change them before the next Product Release.
False
True
False
The PO should never be afraid to change the vision or tactics based on marketplace changes. Being able to strategically re-pivot and capture value in new and different ways is one of the key benefits of an Agile mindset.
The Product Owner should be expertly aware of the marketplace for the product.
True
False
It depends
True
The Product Owner should be expertly aware of the marketplace for the product. They should constantly be gathering and re-gathering information and data regarding the marketplace, so that the product value is maximized. Getting out of touch with the marketplace can be a recipe for product disaster.
How frequently product releases should occur?
Frequently enough to eliminate the risk that the product’s value will get out of line with the marketplace Every Sprint By the end of Product development Every 3 months At least every 6 months
Frequently enough to eliminate the risk that the product’s value will get out of line with the marketplace
While Scrum doesn’t require a release to occur every Sprint, it should be noted that the more elapsed time that accumulates since the last release, the higher the risk that the product’s value will get out of line with the marketplace. Product Owners should keep this risk in the forefront of their mind. Looking at it another way, the sooner you release, the sooner you can start capturing the value created by the product.
The Sprint Review is just a demo of the Product Backlog items completed during a Sprint. Do you agree?
Yes. There is no much difference.
No, the Sprint Review contains much more activities
No, the demo also should include the Items completed in the previous Sprints that were not demonstrated for some reason
No, the Sprint Review contains much more activities
No. The Sprint Review contains much more activities to inspect the Increment and adapt the Product Backlog.
For example:
The Product Owner also explains what has not been “Done”;
The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality.
Who decides whether to release the latest increment of the product?
The Scrum Master The Product Owner and The Scrum Master The Product Owner The Scrum Team The Development Team
The Product Owner is the one and only person who can decide whether to release the latest increment of the product.
Select the three best options to finish the sentence below.
Technical debt …
is a real risk which can genuinely be incurred
is a lack of technical supplies
compromises long-term quality of the Product
reflects some extra development work
belongs entirely to the Development Team. No one else should know about it.
is a real risk which can genuinely be incurred
compromises long-term quality of the Product
reflects some extra development work
Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. In other words it can be defined as the longer term consequences of poor design decisions. Technical debt is a real risk which can genuinely be incurred. It compromises long-term quality of the Product.
One of the ways of handling technical debt is recording it on the Product Backlog. So, it becomes visible to the Scrum Team.
Who is responsible for crafting the Sprint Goal at the Sprint Planning?
The Scrum Master The Development Team The Key Stakeholders The Scrum Team The Product Owner
After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.
The Scrum Master should not allow the Product Owner to attend the Sprint Planning if the PO is not ready with a Sprint Goal. Is this true or false?
True
False
False
False. The Scrum Team crafts a Sprint Goal during the Sprint Planning.
What could be a source of requirements for any changes to be made to the product?
The CEO of the Organization
The Product Backlog
The Key Stakeholders
The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.
