Scrum PSD Professional Scrum Developer 1 (PSD I) Exam Practice Test

Managers doing performance reviews by comparing one programmer’s code to another’s

Two developers writing code together, providing constant peer review

Two programmers writing code separately, but always review each other’s pull requests

Developer and tester work together to write and test code

They may update estimates for Product Backlog items.

They do not. The Scrum Master and the Product Owner are responsible for Product Backlog refinement.

They give input on technical dependencies.

They do not. The Developers are only responsible for prioritizing technical work.

They ask QUESTION NO:s to clarify the intent of Product Backlog items.

Code with low cyclomatic complexity

Code with minimal duplication

Code that has not been peer reviewed (yet)

Code that has been peer reviewed

It is a great way for Testers to contribute early in the Sprint as they can start creating all the tests from the beginning.

It increases collaboration between Developers as it requires Pair Programming.

It helps to identify gaps in understanding the desired behavior.

It might lead to better code as refactoring is part of the Test-Driven Development cycle.

It helps break down complex problems into smaller ones that are much easier to be tackled.

It makes Integration Tests obsolete and by doing so saves a lot of time.

Finding bugs

Tracking quality metrics

All developers are responsible for quality

Verifying the work of the programmers

Scrum has no tester role

transparency

planning

inspection

respect

commitment

adaptation

It is a complete user story with all the necessary components

It is well understood by the developers and product owner at the sprint planning

It has been changed from unready to ready status in the tracking tool

It has been fully described in the user requirements analysis

It can most likely be done within one sprint

The need for a stable velocity

The benefit of the teams figuring it out theirselves

The need to have all developers busy with work

The ability of the scrum teams to produce integrated increments

The degree to which the system under test has been exercised by tests.

The number of Developers that understand how the code works.

An insurance policy that covers the code for defects.

The percentage of code in version control included in a build.

Cancel the Sprint.

Immediately raise the issue to the Scrum Master.

Complete the work that can be done and complete the remainder during the "hardening sprint".

Stop using Scrum until the impediment is resolved.

Drop the Product Backlog items affected by the impediment from the Sprint Plan.

The behavior of a given object can be emulated to the system under test

They are machine-generated and eliminate the need to write code by hand

To increase tight coupling

TDD is impossible without them

Isolating a particular system component for controlled testing

Screenshots or pictures of the bug in action, if possible

Explains some new system functionality desired

Includes build or version number where bug was found

Expected results and observed results

Provides simple and repeatable reproduction steps

Includes code for a proposed fix

Manage the meeting

All of these

Lead the discussion

Ensure that the meeting takes place and that its timebox won't be exceeded

Make sure all three questions of the daily scrum are answered

A mock helps you create a build script

Mocks, stubs, dummies, fakes and shims are all the same

A mock is a way to initialize the database for testing

A test object that mimics the behavior of a dependency in the system under test

False

True

Just before the first check-in

Just before the product is released

When the product owner asks for a build

Just before the end of the sprint

As soon as there is code in the version control system

Create a plan for testing the application

Identify tools and techniques to be used in testing the product

Define acceptance criteria for features

Delay test activities until a feature has been coded

True

False

Meet with the business analyst to ensure that the test is correct.

Write the minimum amount of product code to satisfy the test.

Run it again to make sure it really fails.

Implement the required functionality.

Refactor the test so the code passes.

The ratio of the number of tests to lines of code in the system being tested

The quality of unit tests being written

Code being exercised by tests

The absence of defects in code

When a feature is done

Because testers are terrible coders

Because the tests are checked in before the code exists

Because the product code to satisfy the test doesn’t exist yet

Because the test needs to be refactored

It is designed along with the vision, before the first Sprint.

In the beginning of the project, during Sprint 0.

Before writing code.

Throughout development, as understanding emerges.

True

False

An incremental and emergent approach to software design

A software development technique based on automated tests

A predictable way to develop working well-organized code

Creating a manual test script before writing code

Having testers involved in the development process

Deductive

Hybrid

Empirical

Technical

The Developers may forecast less overall work in Sprint 8.

Stakeholders will encourage the Scrum Team to estimate better during the Sprint 8 Planning Meeting.

There is nothing wrong. The Developers will present all Product Backlog items selected for Sprint 7 at the end of the Sprint.

The Developers carry over incomplete Sprint Backlog items from Sprint 7 to Sprint 8 and monitor the Sprint 8 burn-down chart. As soon as deviation from trends is detected, the Developers work with the Product Owner to negotiate remaining work.

The Scrum Master adds additional Developers for Sprint 8.

The Developers put incomplete Product Backlog items back into the Product Backlog for re-ordering. The Product Owner may ask the Developers to complete the unfinished Product Backlog items from Sprint 7 in Sprint 8.

The product owner speaks on their behalf

The developers self-manage and they are the only management required at the daily scrum

The scrum master speaks on their behalf

The scrum master lets them know whether they need to be preset

Add the item to the next sprint

Add the item to the current sprint and work harder

Add the item to the current sprint and leave out something that is less important

Inform the product owner, so the PO can deal with the CEO

Scrum requires no documentation

Technical writers

Scrum master

Product owner

Developers

Doing all work needed to meet the Definition of Done.

Updating Sprint tasks properly in the electronic tracking tool.

Keeping track of and estimating all undone work to be completed in a “hardening" Sprint.

Reporting Sprint progress to the stakeholders daily.

Release documentation

Build automation

Security

Design pattern choices

Scalability

To make the code more readable

To make it easy to distinguish between different software products

To communicate the identity of the developer that wrote the code

To reduce friction in a shared codebase

To ensure that orphan functions are not created

The sprint backlog

The product goal

The Sprint goal

Sprint review minutes

Scrum requires a specific set of development practices

Scrum is complemented by good development practices

Scrum requires all development practices

Scrum has no relationship to development practices

Continuous Integration / Continuous Deployment / Continuous Delivery.

Blue-Green-Deployment.

Hypothesis-Driven Development.

Vertical Teams.

Blameless Post-Mortems.

All of the above.

Analyze, describe, and document the requirements for the subsequent Sprints.

Define the major product features and a release plan architecture.

Make up a plan for the rest of the project.

Create at least one valuable and useful Increment.

It defines a state when the entire Increment is releasable.

It might be a subject of discussion during the Sprint Retrospective.

It is synonymous with acceptance criteria.

It is the sole responsibility of the Developers to define it.

It can only be extended; nothing can be removed.

An approach to make decisions easier to change in the future and find the best possible point in time to make decisions.

Starting development of a software product requires a clear understanding of the underlying software architecture, and Emergent Architecture describes the process of creating this final architecture.

In Scrum there is no Architect-Role; therefore, architecture emerges naturally.

Enterprise Architects must be involved to create the foundation of each software product.

The software architecture emerges solely from decisions the Developers make from a technical perspective.

Handle them during a risk mitigation phase before development

Scrum is for functional, frontend development only

Include them in the Product Backlog

Before the release, they should be tested and validated in a hardening sprint

Specific expectations can be used as acceptance criteria to specific product backlog items

Important, recurring non-functional requirements can be added to the definition of done

True

False

The scrum master ends the meeting when it is done

This is for the developers to decide

At most 15 minutes

At least 15 minutes

Around 15 minutes, but more if necessary

Meet with the team to see why it fails

Change the test in a way that is passes

Run it again to verify it fails.

Write the code to satisfy the test

Behavior driven development

Scrum testing

Regression testing

Acceptance test driven development

True

False

During the sprint planning when they can’t fit enough into the sprint

Prior to starting a new sprint

In the retrospective when it turns out they can improve quality

Prior to starting a new project

From the beginning and throughout all Sprints.

When the implementation of each feature is complete.

After Sprint Review.

When the product is feature complete.

When the developers feel they aren't ready

When the project manager decides this.

Never, the sprint must always be finished.

When the sprint goal becomes obsolete

When all the tasks are completed by the Developers.

When the Sprint Retrospective is complete.

When all Product Backlog items meet their Definition of Done.

When the Product Owner decides enough has been delivered to meet the Sprint Goal.