PSD I Practice Assessment 2

Developers should have some guidelines for deciding and handling architectural and infrastructural concerns. They should handle these concerns as a part of other Product Backlog Items during each Sprint. Doing a lot upfront in order to make a comprehensive architecture at the beginning of the project is a type of waste. Handling architecture should be done incrementally based on the learnings that emerge during the Sprints. It is obvious that it uses more effort at the early Sprints and decreases during the middle and last Sprints. On the other hand, during each Sprint, the Team should try to produce at least one potential releasable business functionality in order to get feedback from customers. Therefore, adding architectural and infrastructural items to the Product Backlog in order to do in the early Sprints is a valid policy.

Handling architecture should be done incrementally and continuously based on the learnings that emerge during the Sprints. It is obvious that it uses more effort at the early Sprints and decreases during the middle and last Sprints

TDD or Test-Driven Development or Test-First Development is a development process that has three steps:
Step 1 – Write a test and run it to fail
Step 2 – Write just enough code to pass the test
Step 3 – Refactor the written code
Another metaphor for TDD is: Red – Green – Refactor

The goal of Continuous Integration (CI) is to provide rapid feedback of build and test results so that if a defect is introduced into the code base, it can be identified and corrected as soon as possible. So, with any check in of new or changed code into version control, the build should be executed.

The goal of Continuous Integration (CI) is to provide rapid feedback of build and test results so that if a defect is introduced into the code base, it can be identified and corrected as soon as possible. In addition, the person who is in the context and knows what is happening is the best one to fix it.

All requirements have some desirable and undesirable scenarios. Having a quality product needs to manage all these scenarios. Therefore, each requirement could break down into some functionality flow. Following expressions are used for this subject:
• Sunny Day, Rainy Day
• Happy Path, Sad Path
• Main Path, Alternate Path
• Main Course, Alternate Course
In addition, it is used widely in Use Case driven development.

BDD combines practices from Test-Driven Development (TDD) and Domain-Driven Design (DDD) along with the collaboration of development team and domain experts. BDD uses a simple Domain-Specific-Language (DSL) using natural language structure based on the ubiquitous language that can express the behaviors and the expected outcomes. For more information, BDD does not have any formal requirements for exactly how user stories must be written down but Gherkin is a wide-used format to write down the requirements in the BDD approach. BDD is also referred to as Specification by Example and is a synthesis and refinement based on TDD and Acceptance Test-Driven Development (ATDD) practices.

Dynamic Analysis is executed while a program is in operation. A dynamic test will monitor system memory, functional behavior, response time, and overall performance of the system. On the other hand, Static Analysis is performed in a non-runtime environment. Typically, a static analysis tool will inspect program code for all possible run-time behaviors and seek out coding flaws, back doors, and potentially malicious code.

Mock objects are simulated objects that mimic the behavior of dependent real objects in controlled ways. A mock object is a type of Test Doubles. There are at least five types of Test Doubles: Test Stub, Mock Object, Test Spy, Fake Object, and Dummy Object with some differences.

Code coverage is a measure used to describe the degree to which the source code of a program is executed or exercised when a particular test suite runs. Note that 100% coverage will not assert that the quality is perfect, but a low number will tell you that you have insufficient testing and the source code is error‐prone. In addition, for code coverage calculation all unit tests should be passed.

Code coverage is a measure used to describe the degree to which the source code of a program is executed or exercised when a particular test suite runs. Note that 100% coverage will not assert that the quality is perfect, but a low number will tell you that you have insufficient testing and the source code is error‐prone. There is a tendency as a shortage to write tests in order to just increase the code coverage rather than discovering bugs. In addition, code coverage does not ensure that the most sensitive and important portions of the code are tested and does not necessarily provide functional coverage.

Running automated tests in automated builds guarantees that every build is tested for bugs. If any bug in the code arises, it is better to detect and fix it as soon as it appears. Using automated tests in automated builds makes it possible to discover bugs in the shortest period when it is easier to find the reason of the bug and fix it. This allows software developers to find and correct more errors before the application is released.

There are many code metrics. Some of them measure code quality and others just prepare information about code situations.
Metrics that measure code quality: Class Coupling, Depth of Inheritance, Efferent Coupling, Afferent Coupling, Instability Index, Cyclomatic Complexity, Maintainability Index.
Metrics that do not measure code quality: Code Coverage, Lines of Code

There are several attributes that a bad bug report could have such as vague statements or untested assumptions, assigning blame, with no screenshots or other attachments, with no expected results and observed results, with no version and build of the software under test, having no simple and repeatable reproduction steps, generic titles, with no date and time that the defect occurred or reported, with no reporter name, etc.

TDD is one of the most important concepts in Agile so we explain it widely as following:
• Because you are writing small tests at a time, it forces your code to be more modular (otherwise they’d be hard to test against). TDD helps you learn, understand, and internalize the key principles of good modular design.
• TDD also forces good architecture. In order to make your code unit‐testable, it must be properly modularized. Writing the tests first, various architectural problems tend to surface earlier.
• Documents your code better than documentation (it doesn’t go out of date since you’re running it all the time).
• Makes code easier to maintain and refactor. TDD helps to provide clarity during the implementation process and provides a safety net when you want to refactor the code you have just written.
• Makes collaboration easier and more efficient, team members can edit each other’s code with confidence because the tests will inform them if the changes are making the code behave in unexpected ways.
• Because TDD essentially forces you to write unit tests before writing implementation code, refactoring of code becomes easier and faster. Refactoring code written two years ago is hard. If that code is backed up by a set of good unit tests, the process is made so much easier.
• Helps prevent defects – well, at least it helps you find design or requirement issues right at the beginning. TDD provides early warning to design problems (when they are easier to fix).
• Helps programmers really understand their code.
• Creates an automated regression test suite, basically for free. i.e. you don’t need to spend time afterward writing unit tests to test the implementation code.
• It encourages small steps and improves the design because it makes you cut the unnecessary dependencies to facilitate the setup.
• It helps to clarify requirements because you have to figure out concretely what inputs you have to feed and what outputs you expect.
• Unit tests are especially valuable as a safety net when the code needs to be changed to either add new features or fix an existing bug. Since maintenance accounts for between 60 and 90% of the software life cycle, it’s hard to overstate how the time taken upfront to create a decent set of unit tests can pay for itself over and over again over the lifetime of the project.
• Testing while writing also forces you to try to make your interfaces clean enough to be tested. It’s sometimes hard to see the advantage of this until you work on a body of code where it wasn’t done, and the only way to exercise and focus on a given piece of code is to run the whole system and set a break‐point.
• “Stupid” mistakes are caught almost immediately. It helps developers find mistakes that would waste everyone’s time if they were found in QA.

When you find a bug that has already been delivered to the market, at first estimate the amount of work needed to fix it. If it is small, do it in the current Sprint and just inform the Product Owner. However, if it is not small talk to the Product Owner to put it on the Product Backlog.

Don’t repeat yourself (DRY) is a principle of software development aimed at reducing repetition and duplication of software codes.

A unit test is a separated and isolated test that validates a unit of functionality. A good unit test should have the following characteristics:
• Does not depend on the environment; e.g. it will run on your computer and it will run on your colleague’s computer
• Does not depend on other unit tests
• Does not depend on external data
• Does not have side effects
• Asserts the results of code
• Tests a single unit of work (mostly a method)
• Covers all the paths of the code under test
• Tests and asserts edge cases and different ranges of data
• Runs fast
• Is well‐factored and as small as possible
In addition, they usually use Test Doubles to resolve dependencies

Technical debt comes from making bad technical decisions and is the eventual consequence of poor technical choices. The Team should pay it back continuously. If the Team does not pay back, it will decrease the development speed over time. Although its measurement is hard, its growth would lead to wrong assumptions about Increments delivery and even might prevent creating the releasable product.

Branching is the practice of creating isolated copies of programs or objects in development to work in parallel versions, retaining the original and working on the branch, or making different changes to each. Each copy is considered a branch; the original program from which the branch is taken is referred to as the trunk, the baseline, the mainline, or the master.

Naming Convention has the following benefits:
• To reduce the effort needed to read and understand source code;
• To enable code reviews to focus on more important issues than arguing over syntax and naming standards;
• To enable code quality review tools to focus their reporting mainly on significant issues other than syntax and style preferences;
• To help formalize expectations and promote consistency within a development team;
• To enable the use of automated refactoring or search and replace tools with minimal potential for error;
• To enhance clarity in cases of potential ambiguity;
• To enhance the aesthetic and professional appearance of work product (for example, by disallowing overly long names, comical or “cute” names, or abbreviations);
• To help avoid “naming collisions or frictions” that might occur when the work product of different organizations is combined;
• To provide meaningful data to be used in project handovers which require submission of program source code and all relevant documentation;
• To provide a better understanding in case of code reuse after a long interval of time.

Orphan, dead or unreachable code is a code that will never be executed. It shows itself as variables that are declared but never used, functions that are never called, or code that is skipped because of a condition branch.

Lines of Code is the number of lines in the text of the program’s source code with the following characteristics:
• A high count might indicate that a type or method is doing too much work
• A high count might also be a warning that code will be hard to maintain
• It isn’t a code quality metric

Afferent coupling measures how many classes depend on a given class and has the following characteristics:
• Classes with high afferent will affect other classes when changes are made.
• A large afferent coupling can indicate that you should reconsider the responsibilities of the class, because It will be very difficult to make changes to this class later when so many other classes are dependent on it
• It is a code quality metric

Efferent coupling measures the number of classes on which a given class depends and has the following characteristics:
• Classes with high efferent coupling will receive the effects of changes or defects in other classes
• A large efferent coupling can indicate that a class is unfocused and may also indicate that it is unstable since it depends on the stability of all the types to which it is coupled
• It is a code quality metric

S.O.L.I.D is an acronym for the first five object-oriented design (OOD) principles by Robert C. Martin, popularly known as Uncle Bob. These principles, when combined together, make it easy for a programmer to develop software that is easy to test, maintain, and extend. They also make it easy for developers to avoid code smells, easily refactor code, and are also a part of the agile or adaptive software development.
Continuous Integration, Continuous Delivery, Continuous Deployment, and LOC do not relate to the testability level of code.

SOLID principles are described as the following:
Single Responsibility principle: A class should have one and only one reason to change, meaning that a class should have only one job.

Open-Closed principle: Objects or entities should be open for extension, but closed for modification.

Liskov Substitution principle: Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

Interface Segregation principle: A client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend on methods they do not use.

Dependency Inversion principle: Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but it should depend on abstractions.

Liskov Substitution principle: Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

The principle of least privilege (PoLP; also known as the principle of least authority) is an important concept in computer security, promoting minimal user profile privileges on computers, based on users’ job necessities. It can also be applied to processes on the computer; each system component or process should have the least authority necessary to perform its duties. This helps reduce the “attack surface” of the computer by eliminating unnecessary privileges that can result in network exploits and computer compromises.

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Advantages include improved code readability and maintainability and reduced complexity. To sum up, because the external behavior of the code is not altered so there is no chance to improve user experience through refactoring.

Developers are responsible for doing all the required tasks to create a potentially releasable Increment. Documentation same as other tasks is a part of the development. Therefore, each Developer who has sufficient documentation skills can create the required documentation.
In addition, postponing some tasks to the future for example right before a release increases risks and prevents creating done Increment in order to gather feedback from the market.

The instability index measures efferent coupling in relation to total coupling:
Instability Index = Ce / (Ca + Ce)
Ce: Efferent Coupling
Ca: Afferent Coupling

The instability index measures efferent coupling in relation to total coupling:
Instability Index = Ce / (Ca + Ce)
Ce: Efferent Coupling
Ca: Afferent Coupling
This metric has a range [0,1]. A value of 1 means a code component is highly unstable, and a value of 0 means it is highly stable.

Developers are responsible for doing all the required tasks to create a potentially releasable Increment. Writing tests like other tasks is a part of the development. On the other hand, each Scrum Team should be cross-functional so having a dependency on other teams violates this rule. Therefore, the Developers are responsible for writing tests.

An architecture spike is an experiment that allows Developers to learn just enough about the technical and unknown elements of an architecture solution. Often, a spike is a quick and dirty implementation, a prototype that will be thrown away. There are many synonyms for spike such as Knowledge Acquisition, Research, Proof‐of‐Concept.

All the Scrum Team members are accountable for the product’s quality. In Scrum, as an adaptive approach, quality and test should be considered from the beginning of the project. It leads to more transparency in Increments, ensures to have releasable Increments, decreases the risk of reworks and as it helps to produce reliable Increments, customer feedback will be around business expectations not about bugs or wrong implementation so it improves customer feedback’s level.

The development environment, tools, and infrastructures required for the development should be prepared and improved gradually during the project. It is obvious that it uses more effort at early Sprints and decreases during the middle and last Sprints. In addition, during each Sprint, the Team should try to produce at least one potential releasable business functionality in order to get feedback from customers.

On the other hand, there is no special time before the first Sprint e.g. Sprint Zero to do such a preparation.

The non-functional requirements or cross-cutting concerns are the features of the design that may apply across all layers and are related to the quality requirements. There are many non-functional requirements as following: Security, Reliability, Performance, Availability, Globalization, Scalability, Maintainability, Robustness, etc. They can be managed by adding them to the Definition of Done, the Product Backlog, or acceptance criteria.

A sandbox is a type of software testing environment that enables the isolated execution of software or programs from the production or live environment for independent evaluation, monitoring, or testing. In an implementation, a sandbox also may be known as a test server, development server, or working directory.

Smoke testing, or “Build Verification Testing”, is a type of software testing that includes a non-exhaustive set of tests that aim at ensuring that the most crucial and important functions work. The result of this testing is used to decide if a build is stable enough to proceed with further testing.
Smoke testing is the preliminary check of the software after a build and before a release. This type of testing finds basic and critical issues in an application before critical testing is implemented.
The term smoke testing originates from a similarly basic type of hardware testing in which a device passes the test if it does not catch fire the first time it turns on.

White-box testing is a software testing method in which the internal structure/design/implementation of the item being tested is known to the tester. The tester chooses inputs to exercise paths through the code and determines the appropriate outputs. Also, it implies testing based on an analysis of the internal structure of the component or system. This method is named so because the software program, in the eyes of the tester, is like a white/transparent box; inside which one clearly sees.

Definition of Done is a concept with a set of requirements that should be applied to a feature in order to be called complete. On the other hand, Acceptance Criteria or Conditions of Satisfaction contains a list of scenarios that should be passed to ensure that the feature is working as expected. The difference is that there is one Definition of Done for the product and is common for all features while there is a separate and specific Acceptance Criteria for each feature. Passing Acceptance Criteria would be an item of the Definition of Done.

Depth of Inheritance implies the maximum length from the node to the root of a code tree. A low number for depth implies less complexity but also the possibility of less code reuse through inheritance. In addition, a high number for depth implies more potential for code reuse through inheritance but also higher complexity with a higher probability of errors in the code. It is a code quality metric.

Testers and QA experts are members of the Developers so they are included in a project from the beginning of the project.

According to the Scrum rules, the Scrum Team consists of one Scrum Master, one Product Owner, and Developers and nothing else. The project manager’s responsibilities are distributed among the Scrum Team. In addition, the Scrum Master or the Product Owner is not the same thing as a traditional project manager.

The Product Owner is responsible to monitor the progress of the project toward a business goal or high-level goals for Sprint Reviews and the Developers are responsible to monitor the progress of the work toward the Sprint Goal for Daily Scrums. Generally, it is not mandatory; however, is a great practice, which supports inspection and adaptation.

Cross-functionality means the Scrum Team as a whole should have all required skills to create potentially releasable Increments without any dependency on others outside the Team. Each individual Developer may have some specialized skills or some focused areas of expertise but they do not need to be cross-functional one by one.

The Developers have many responsibilities as following:

Developing and creating Increments, estimating the Product Backlog Items and tasks, creating the Sprint Backlog, selecting Items for the Sprint Backlog, decomposing selected Product Backlog Items into tasks, measuring Sprint performance and productivity, calculating velocity, resolving Team internal conflicts, collaborating in composing/refining the DoD, making technical decisions, etc.

The Developers have many characteristics as following:

Have no titles, preferably full-time, with no sub-teams, autonomous, self-organizing, self-managing, and cross-functional.

Adding new members to the Team will lead to a temporary reduction in productivity because new member needs time to be familiar with the Team’s environment, culture, and the product and old members need to collaborate on new member’s onboarding. Furthermore, a bigger Team does not mean that it can create more value. It is recommended to change Team composition at the beginning of the Sprints.

The Scrum Team is self-managing and cross-functional that should try not to ask for outside help if possible. All Team members are accountable for the Team’s productivity and they should help their teammates if needed. Therefore, if the Scrum Master could not remove some impediments, she or he can ask her (his) teammates i.e. the Product Owner or the Developers for help.

The Product Owner is accountable for maximizing the value of the Developers’ work. Changing the Sprint Backlog items in the middle of the Sprint may endanger the Sprint Goal and interrupt Team’s focus. So, in this case, the Developers should inform the Product Owner so that (s)he can work with the one who has ordered unplanned work.

On the other hand, accepting unplanned work does not mean you are creating the highest value. In addition, respect does not mean you should always create all things that the stakeholders want because it may not necessarily create value.

The Developers try to produce a done usable and potentially shippable and releasable Increment and piece of working software in each Sprint.
On the other hand, finishing their tasks does not necessarily mean they will create a releasable Increment because they may miss some tasks for converting the selected Product Backlog Items into a done Increment.

If the Team does not complete all Sprint Backlog Items at the end of the Sprint, the Sprint will be over with the completed Items. There is no blame or other same things. However, it is a valuable fact as an input for the Sprint Retrospective to inspect if there is any problem in the development process or anything else.

Extending or shortening a special Sprint duration is forbidden. Undone Items should not be included in the Increment. Instead, all undone Items should be re-estimated and move back to the Product Backlog and if through Product Backlog ordering, these Items remain on top of the Product Backlog, they can be selected for the next Sprint.

There are totally 5 events in the Scrum framework as Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective which the Sprint is a container for other events.

The Sprint Review time-box is 4 hours for one-month Sprints and usually shorter for shorter Sprints.

There is a difference between participation and attendance in Scrum events which participation means actively talking during the event but attendance means just listening and observing.

There is just regular Sprint in Scrum within which the Developers try to create releasable Increment. Therefore, there are no such things as Sprint Zero, Hardening Sprint, Stabilization Sprint, Integration Sprint, etc.

The Developers have not closed their planning yet, so can change their Sprint Backlog even selected PBIs. Therefore, they can remove some Items from the bottom of the Sprint Backlog, or inform the Product Owner and at the end of the Sprint adjust the work with the Product Owner’s collaboration. As a tip, adding more developers to the Team based on the more selected PBIs during the Sprint Planning is not acceptable because adding new members to the Team leads to a temporary reduction in productivity. In addition, adding new members should be based on long-term needs.

Sprint Planning is a mandatory event of Scrum and is a feedback loop that Team members can inspect the Product Backlog and select enough work to develop during the Sprint. It should be conducted at the beginning of each Sprint.

Sprint Review is a mandatory event of Scrum and is a feedback loop that Team members demonstrate the Increment to the stakeholders, elicit feedback, and determine likely PBIs for the next Sprint. Also, the latest forecasted project end date, budget, market status, new capabilities, and insights about the project could be discussed. It should be conducted at the end of each Sprint before the Sprint Retrospective.

Sprint Review is a mandatory event of Scrum and is about the Product. In addition, the Sprint Retrospective is also a mandatory event of Scrum and is about the Scrum Team and processes.

In the Scrum Guide 2020, the limit of no more than 10% capacity of the Developers has been removed. On the other hand, it is really context-sensitive so the Scrum Team as a whole decides on it, not just the Scrum Master alone.

Fundamentally the Sprint Review is an inspect and adapt loop, not just a demo meeting. The most important topics in this event are:

– The Scrum Team presents the results of their work to key stakeholders, progress toward the Product Goal is discussed, and feedback is elicited and gathered.

-Check how the current Sprint went and if the Sprint Goal was achieved or not

-Adapt Product Backlog through the Team and stakeholders’ collaboration to determine things that can be done during the next Sprint

-The Product Owner explains the project status and the latest forecast of the project completion date

-Stakeholders collaborate with the Team to adjust the budget, inspect market status and every project level interesting things

-Is an informal meeting and there is not any hand-off / sign-off in it

In the Sprint Review, the Team and stakeholders collaborate on adapting the Product Backlog to nominate things that can be done during the next Sprint.

In Scrum, task and work are two keywords with the same meaning that are used to break down the PBIs. Tasks are the activities that need to be done by the Developers in order to create usable and releasable Increments. As explained, Scrum is founded on an adaptive approach and the Developers should inspect and adapt the work continuously. Therefore, each time they find a new task or work for each PBI in the Sprint Backlog, they can add that task to the Sprint Backlog and even they can remove some tasks.

The Developers own the Sprint Backlog so the Scrum Master and the Product Owner should not change it.

There are three elements in the Sprint Backlog: Sprint Goal, Sprint Backlog Items, and Tasks.

The ownership of all three elements is shared and belongs to the Scrum Team not individual members in order to distribute the same level of accountability over all members.

There is no assignment for the Sprint Goal.

In addition, there is no assignment for a Sprint Backlog Item because it contains some tasks when are done, the result will be a done Sprint Backlog Item.

Tasks are assigned to the individual Developers with an agreement by all teammates.

The Developers are self-managing and assign tasks to themselves with an agreement by all teammates. In addition, nobody (e.g. the Product Owner, the Scrum Master, and the Project Manager) should assign tasks to them or order them how to do their work.

In Sprint Planning, usually, enough tasks are defined for the early days of the Sprint and other tasks emerge during the Sprint when the Developers learn more about the work.

Feature’s done or completeness can be explained through the following statements:
– When everything is done based on the Definition of Done
– When there is nothing more to do before it can be used by the end users
– When it is potentially releasable and shippable
– The Item is usable by the end user

Definition of Done is a fundamental concept of Scrum which creates a common understanding of when work is complete, helps Developers understand how many Product Backlog items they can select for each Sprint, and increase transparency. In addition, it can be considered as a development process and could be contained many things such as quality criteria, metrics, non-functional requirements, etc.

Scaled Scrum is based on the Scrum framework and uses Scrum parts as its building blocks with some additions or changes within which multiple teams work on the same product for one or more Sprints in order to produce a releasable integrated Increment at the end of each Sprint.

Scrum.org has introduced the Nexus framework for this purpose with some differences with scaled Scrum, which contains 3-9 Scrum Teams and a Nexus Integration Team.

In scaled Scrum, each Team creates their done Increment and they integrate their work on a daily basis. However, the integrated Increment as a whole, which contains all Teams’ outputs is used to be demonstrated in the Sprint Review.

When multiple Teams are working on the same product they can (not should) have one Definition of Done for all Teams or each Team can have its own one or something between these two extremes. The rule here is that their outputs should be combined and integrated continuously and at the end of the Sprint they should deliver just one integrated Increment as all Teams’ output so all Definition of Done should not violate each other.

In scaled Scrum which multiple Teams work on a single Product, there is just one Product Owner, multiple Teams of Developers, and one Scrum Master position for each Team that can be filled with one or multiple Scrum Masters.

Developers should be fast and nimble through their productive processes and individuals’ skills not by working overtime, organizational policies, or forces. Overtime is a symptom that there are some problems in the process or environment. On the other hand, establishing a balance between work and personal life leads to better productivity that occurs at a sustainable pace. This sustainable pace is usually between 6 and 8 hours a day. Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.

Sprint burn-down chart indicates the remaining work of each day during the Sprint. Its Y-axis shows the total remaining work and the X-axis shows Sprint days. If you draw a trend line from the Sprint beginning remaining work to the last day of the Sprint on the X-axis, you will have the plan trend line and you can compare actual and plan progress daily in order to resolve deviation as soon as possible if needed. Increasing the remaining work during the Sprint is natural because new tasks can emerge when the Team learns more about the work.

According to the Scrum Guide, mandatory elements of Scrum are Scrum Accountabilities, Scrum Events, Scrum Artifacts with their commitments plus the rules that bind them. Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.

Other things are practices that can be employed in the Scrum framework and are up to the Team and project and are not mandatory.

Developers are self-managing and no one tells them how to perform work and turn the Product Backlog into Increments of potentially releasable functionalities. In addition, Developers as a whole are cross-functional with all required skills to create a product Increment.

Scrum is based upon five core values: Commitment, Focus, Openness, Respect, Courage.