Agile Scrum Developer

3 reasons why automated builds are important?

1. They allow frequent validation of the unit of software being worked on, ensuring it remains in a potentially shippable state.
2. They support continuous integration.
3. The build process is clearly defined and scripted, making it easy consistent and repeatable.

What is Test-Driven Development?

• A software development technique based on automated tests.
• An incremental and emergent approach to software design.
• A predictable way to develop working, clean code.
• Testing existing software before developing any new software.

What does a test written with Test Driven Development represent?
A technical requirement that must be satisfied.

Since the test exists before the code that makes it pass, the test acts as a requirement of the system under test.

4 desirable characteristics of a unit test.

1. The test executes fast.
2. Code in each test is as small as possible while maintaining readability of the code
3. Each test is independent of other unit tests.
4. Each test makes assertions about only one logical concept.

Programmers and testers should not be included in refining Product Backlog items.
False

What are 2 reasons to automate the software build process?

Automation improves the quality of software by making builds less error-prone.

To get feedback on changes to the code early and often.

What does Code Coverage show?
Code being exercised by tests

Describe the practice of expressing requirements as acceptance tests?

Acceptance Test Driven Development

Advanced practices of test-driven development can lead to Acceptance Test-driven development (ATDD) where the criteria specified by the customer are automated into acceptance tests, which then drive the traditional unit test-driven development (UTDD) process.

Product Backlog items are refined by:
The Development Team and the Product Owner

Who writes tests in a Scrum Team
The Development Team

What are metrics of code quality? 

• Class coupling
• Depth of inheritance
• Cyclomatic complexity

Note regarding Code Coverage: Code Coverage might be an indicator, but it would not be considered a metric of Code Quality.

Who should be present during Product Backlog refinement?

The Development Team. The Product Owner.

Which are the benefits of Test Driven Development?

• It promotes good design and separation of concerns.
• It improves quality and reduces bugs.
• It causes you to construct a test harness that can be automated.
• It speeds the overall development process.

What relationship does Scrum have to technical practices?

• Scrum Development Teams with excellent technical practices will likely be more successful.
• While technical practices aren’t specifically included as a part of Scrum, the rapid pace of development using Scrum often requires that good technical practices are utilised by Development Teams in order to be successful.

Which are attributes of a good bug report?

• Clear title and proper grammar in report.
• One bug per report.
• Simple and repeatable reproduction steps.
• Expected results and observed results.
• Build/version where bug was found.
• Screenshots or other pictures of bug in action when user interfaces are involved.

When does the Development Team participate in Product Backlog refinement?
Anytime during the Sprint.

Which are three attributes of a bad bug report?
Generic titles. Vague statements or untested assumptions. Assigning blame.

What happens during Sprint 0?
Scrum does not include the concept of a Sprint 0. “Sprint 0” has become a phrase misused to describe the planning that occurs prior to the first sprint.

Should User Stories be part of the documentation generated by a Scrum project?
If they are part of the Definition of “done”.

What are some shortcomings of code coverage as a measurement for how well a system or product is tested? 

• Code coverage does not ensure that the most important or highest risk areas of the code are being exercised by tests.
• Code coverage does not necessarily provide functional coverage.
• Could create incentives to write tests that simply increase code coverage, rather than tests that find bugs without increasing coverage.
  Code coverage is a useful metric, but not in isolation. It should not be considered a replacement for effective test design techniques.

You are on a Scrum Team that is enhancing an existing product. Which is the LEAST useful piece of documentation you want to have at your disposal?
The full history of retrospective plans and lessons learned.

What is test first development?

Designing tests before satisfying them.

While changing software, you find a bug in a previously delivered piece of functionality. What should you do?

• Fix the bug if it is critical or easily fixed. Otherwise, put the new bug into the Product Backlog to be prioritised and fixed in an upcoming Sprint.
• Unless your company has specific guidance on fixing bugs, they represent work to be done and should be ordered on the Product Backlog by the PO.
• Two exceptions are if the work to fix the bug is less than the work to actually file it, or if the bug is so critical that it would be negligent to leave it unfixed.

What is Technical Debt?

A term representing the eventual consequences of poor technical choices.

2 benefits of Continuous Integration?

1. Causes team members to consider each other’s work and context.
2. It leads to higher transparency and rapid feedback to the team.

Which is the best answer for how often the build should be executed?

Whenever new or changed code is checked into version control.

Which is a benefit of establishing naming standards for code?
To make the code more readable.

What is the value of refactoring code?

To improve readability and maintainability.

When is a system’s architecture decided?

Throughout the project, as understanding emerges and the Development Team learns more about the project. Whenever the assigned architect can join the Development Team. It is designed along with the vision, before the first Sprint.

What is an architecture spike?

A small development activity to learn about technical elements of a proposed solution

The Development Team uses some time in each Sprint to analyse, estimate and design high ordered Product Backlog items.

The name of this activity is Product Backlog Refinement. 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.

Product Owner

In order to make investment decisions, the Product Owner is likely to look at the Total Cost of Ownership (TCO) of the product being built. What costs will a Product Owner take into account?

• All investments required to conceive, develop, operate and maintain the product.
• The owner of a product is not only accountable for development and release of a product, but also the cost of maintaining and operating the product. If a person ‘owns’ the product, he/she can be expected to be responsible for the complete lifecycle of a product.

Which description best fits the role of the Product Owner?

Value Maximiser : The Product Owner is responsible for maximising the value of the product. How this is done will vary widely.

It is mandatory for the Product Owner to monitor and share progress of Product Backlog through:

• Any practice based on trends of work completed and upcoming work.
  Various practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful, but none are mandatory and care should be taken because none can replace the importance of empiricism. What will happen is unknown, no matter what has happened.

What is a Product Backlog?

• It is a living artifact of product requirements that exists and evolves as long as a product exists.
• 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. The Product Backlog evolves as the product and the environment in which it will be used evolves. Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. As long as a product exists, its Product Backlog also exists.

How does an organisation know that a product built through Scrum is successful?

• By releasing often, and updating key performance indicators (KPIs) on value after every release and feeding this information back into work on the Product Backlog
• Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. If a product isn’t released, the opportunity to capture user and market feedback is lost.

To what extent does technical debt limit the value a Product Owner can get from a product? 

1. Technical debt causes a greater percentage of the product’s budget to be spent on maintenance of the product
2. The velocity at which new functionality can be created is reduced when you have technical debt.

The Product Owner manages the Product Backlog. Who is accountable for estimating the effort to complete the Product Backlog items?

• The Development Team. As a collective, they have a complete view of the work needed to transform Product Backlog items into Increments of product.
• The Development Team is responsible for all estimates. The people who will perform the work make the final estimate.

The Development Team finds out during the Sprint that they aren’t likely to build everything they forecasted. What would you expect a Product Owner to do?

Re-work the selected Product Backlog items with the Development Team to meet the Sprint Goal.

Who creates the definition of “Done”?

The Scrum Team, in a collaborative effort where the result is the common denominator of all members’ definitions.

If the definition of “done” is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. The Development Team of the Scrum Team can complement it with elements specific for the product or context.
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.

What two things best help the Product Owner manage the value of a product?

1. The order of the Product Backlog
2. Validating assumptions of value through frequent releases

The Product Owner manages Product Backlog against the assumption that value will be generated. Indications of value on Product Backlog are useful but are only a prediction until validated against users and market.

What is the relationship of the Product Owner and the stakeholders?

• The Product Owner actively asks for stakeholder input and expectations to process into the Product Backlog.
• The Product Owner represents the stakeholders to the Scrum Team, which includes representing their desired requirements in the Product Backlog. The Product Owner has the final call over the Product Backlog.

Is a Product Owner is essentially the same thing as a traditional Project Manager?

No – A traditional project manager is responsible for all aspects of a project; costs, resources, execution, release, planning, capacity. Scrum is a framework for complex product development, regardless of whether the work is organised in projects. The Product Owner is responsible for maximising the value of the product and the work performed, a responsibility that is complemented by the specific accountability of the Development Team and the Scrum Master.

Learning turns into ‘validated learning’ when assumptions and goals can be assessed through results. What is a key way for a Product Owner to apply validated learning?

• Release an Increment to the market to learn about the business assumptions built into the product.
• The Product Owner manages Product Backlog against the assumption that value will be generated. This assumption remains invalidated when not checked against users and market.

What are two typical activities for a Product Owner in a Sprint?

1. Work with the Development Team on Product Backlog refinement.
2. Collaborate with stakeholders, user communities, and subject matter experts.

The Product Owner represents the stakeholders to the Scrum Team. This typically requires active interaction in order to be able to represent stakeholders and their needs. Product Backlog refinement is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.

Can a first Sprint start before the Product Owner has a complete and exhaustive Product Backlog in place?

True – A first Sprint requires no more than a Product Owner, a team, and enough ideas to potentially complete a full Sprint.

Is The Sprint Review the only time at which stakeholder feedback is taken into account?

False – A Product Owner engages actively and regularly with stakeholders. However, to limit the disturbance to the development progress and keep focus high, the stakeholders have a formal role in the process at the Sprint Review only.

What pre-conditions must be fulfilled in order to allow Sprint Planning to begin?

There are no such pre-conditions. Sprint Planning serves to plan the work to be performed in the Sprint. This plan is created by the collaborative work of the entire Scrum Team. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. What can be achieved in this time-box may be influenced by additional practices that are however not prescribed by Scrum.

A dev team member complains at the Retrospective that his comments and suggestions were ignored throughout the Sprint. Which three values are we touching here?
a. Focus
b. Commitment
c. Courage
d. Respect
e. Openness

Openness, courage and respect (c, d, e):

Openness:
Openness enables team members to share their perspectives, feel heard by their peers, and be able to support team decisions.

Courage:
It takes courage to share a dissenting opinion with a team member and engage in productive conflict.
It takes courage to admit our mistakes. This could apply to our technical work, our decisions, or how we conduct ourselves.

Respect:
When there is respect for all opinions and perspectives, we can ensure everyone has the opportunity to be heard. When we feel we have been heard, it is possible to fully support team decisions even if the decision was not our preference.

All scrum teams must have a PO and SM. True or False?
A. False
B. True and they should be available 100% dedicated to the Scrum Team
C. True and the productivity and progress depends on their availability

C is correct. PO, SM and even Dev Team members can work on more than one Product at the same time, but productivity will suffer because of switching focus.

The Project Manager has asked for a status report to the Scrum Master about the progress. What should he do ?
A. Prepare it by himself
B. Tell the PO to prepare and submit to the Manager
C. Ask the DT to include the report into their Sprint Backlog
D. Tell the Manager that status will be visible during the Sprint Review

D (status will be visible at the Sprint Review).
A duty of the Scrum Team is to be transparent. Those who need information are responsible for getting it. So, the manager can investigate the artifacts of the Scrum Team (Product Backlog, Sprint Backlog) and visit the next Sprint Review.

Which two (2) metrics will help a Product Owner establish that value is being delivered?
A) Customer satisfaction
B) Velocity
C) Time to market
D) Budget spent
E) Productivity

A and C are correct. EBM guide: Customer Satisfaction KVM and Time to Market KVA. Budget, velocity and productivity do not contribute directly to capturing Product value.

A Product Backlog is (choose 3):
A) Managed by the Product Owner.
B) Ordered based on priority, value, dependencies, and risk.
C) An inventory of things to be done for the Product.
D) An exhaustive list of upfront approved requirements to be implemented for the system.
E) Only visible to the Product Owner and stakeholders.

A, B and C.
E is wrong because all the Scrum Team members can see the Product Backlog.
C and D answers are similar. I like C better because a Product Backlog is never complete, so it cannot be exhaustive. From the other side, if a requirement is in the Product Backlog, it is approved by the PO. So, “an exhaustive list of upfront approved requirements” could be also valid.

Nexus Scaled Scrum

A system is decomposed into elements like workflows, features, capabilities, etc. How it affects Scrum Teams on a scaled project?
It will be reflected in the implementation.

Two ways how Dev Teams can ensure a good application architecture?

1. Architecture is an ongoing discussion
2. The DT should have a set of architecture principles and follow them

How to start a big complex project?
Form 1-2 teams of best developers for implementing the core, add more teams later.

You’re a product lead with a good track record and the organization has asked you to take the lead of a new product. The product will have 6 teams working on it but they are all new to Scrum. You’re starting to form a Product Backlog. How would you minimize dependencies between Scrum Teams?
(A): You identify the dependencies and re-order the Product Backlog for them.
(B): You work with the Development Teams on how to best parse the work.

B –  Nexus Guide has special events for identifying and minimizing dependencies between the teams and forecasting which team will deliver which Product Backlog items: Refinement and Nexus Sprint Planning. Both meetings involve representatives from all the teams.

Multiple Scrum Teams working on the same Product must have the same Sprint start date. Is this statement correct?

No, the statement is incorrect.
The Scrum framework does not require the same Sprint length or aligned Sprints for all teams. So, the start date can be different.

To what extent does technical debt limit the value a Product Owner can get from a product? Select two answers.

1. Technical debt causes a greater percentage of the product’s budget to be spent on maintenance of the product.
2. The velocity at which new functionality can be created is reduced when you have technical debt.

Nexus Scaled Scrum

The purpose of the Nexus Integration team is to:

1. raise transparency
2. provide accountability of integration among the Scrum Teams in the Nexus Integration: be accountable that an integrated increment is produced.

The purpose of the Nexus sprint backlog is:

1. to make dependencies transparent to the teams
2. the composite of Product Backlog items from the Sprint Backlogs of the individual Scrum Teams: to provide a view of all the product backlog items in a sprint.

what two factors should be most considered when establishing the length of a sprint?

1. the level of uncertainty over the technology to be used.
2. the risk of being disconnected from the stakeholders.

true or false: most dev teams working in the same code creates coordination problems which can be sufficiently addressed with a comprehensive branching and merging model in shared version control.

False

management has planned for over 200 developers to work on a new critical product. prior to them being formed into teams and beginning to develop the software, an overall architecture and integrating design is needed. what to do?

true: Form one or two teams of the best developers to create a foundation that represents the non functional requirements and also several high value functions. then increase the number of teams using the shared architecture.

wrong: form a team of architects and designers. this team will serve as consultants to the other scrum teams as integration questions arise during development.

4 teams in a nexus are reporting it takes many hours or days to diagnose integration issues. to address this issue, which technical practice/tool/behaviour would best help?

CI(Continued Integration)

Technical systems can be decomposed to composite elements, from the large to the small. Basic components may be represented as activities, workflows, functions, features, capabilities and other similar nomenclature. How does this system decomposition affect scrum teams on scaled projects?

TRUE: How the organisation discusses and plans the work of creating software will be reflected in the implementation of that software.

wrong: Meta-Scrum teams of up to 200 people are formed. they map themselves into appropriately sized scrum teams for actual development. this may change every sprint. each meta scrum team manages its own decomposition and integration needs.

wrong: scrum teams self organise according to the system decomposition created in design models. the product backlog is similarly decompsoed. people are assigned to scrum teams based on expertise. hardening sprints ensure time for resolving dependencies between teams.

WRONG: There is one scrum team for each functional software layer whose job is to coordinate dependencies, work allocation, integration, testing.

what is the primary purpose of the first part of the nexus sprint retrospective when reps from across the nexus meet?

to identify issues that impact multiple teams.

Reading List

• The New Product Owner
• Coursera: Managing an Agile Team
• Coursera: Testing with Agile
• Coursera: Running Product Design Sprints
• Atlassian’s no-nonsense guide to agile development
• How to do Scrum with JIRA
• How to do Scrum with Trello