PSD I Practice Assessment 1

Among the Developers in a  Scrum Team, there is no title. All members are a developer. Therefore, the Tech Lead, Software Architect, Senior Architect, and Chief Architect are wrong if they are in a Scrum Team. Furthermore, the Developers as a whole are cross-functional means they are not dependent on external resources (e.g. CTO, Chief Architect, Tech Lead …) and the Team has all the required skills for development in itself. In addition, the Developers do all work that needs to produce a releasable Increment of the product such as architecture.

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.

Sketches, wireframes, mockups, and prototypes actually represent the different stages of the design flow. They start from low-fidelity and end with high-fidelity respectively. The sketch is the simplest way to present an idea or initiative, even can be drawn in a piece of paper and has a minimum level of fidelity. Wireframe, a low-fidelity way to present a product, can efficiently outline structures and layouts. A mockup looks more like a finished product or prototype, but it is not interactive and not clickable. However, a prototype has a maximum level of fidelity and is interactive and clickable.

It 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.

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. Dynamic Analysis adopts the opposite approach and 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.

Test Double is a generic term for any case where you replace a production object for testing purposes. 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.

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 good bug report can have such as evidence as screenshots or other attachments, expected results and observed results, version and build of the software under test, having simple and repeatable reproduction steps, having summary and detail description, the date and time that the defect occurred or reported, reported by, impacted related requirement, the severity of the defect, etc.

Pair programming is a technique in Agile Software Development where two engineers share a single workstation. In this technique, one engineer is the driver, who has control of the mouse and keyboard to write the code, while the other serves as the navigator, reviewing the code that the other is writing while providing tactical and analytical feedback. This pair will trade‐off on these roles at regular intervals, giving each other equal chance to both execute on the work or direct it.

In a Scrum Team, all members collaborate continuously. Therefore, anytime if the Developers need feedback from the Product Owner, could ask him/her. On the other hand, anytime the Product Owner asks to see the work, Developers would show the work. In addition, according to the Scrum definition, the Scrum Team usually by Developers demonstrates done work to the Product Owner, Scrum Master, and stakeholders in the Sprint Review meeting.

There are several attributes that a bad bug report can 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 that 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 implemented code.

The following tests can be automated: Unit Test, Integration Test, Component Test, System Test, Functional Acceptance Test, User Acceptance Test and Non-functional Acceptance Test (Capacity, Security, Performance, etc.), etc.
However, the following tests cannot be automated: Exploratory Test, Usability Test, Showcase Test.

When you find a bug that has already been delivered to the market, at first estimate the amount of work needs 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, ask the Product Owner to put it on the Product Backlog.

Advanced practices of Test‐Driven Development can lead to Acceptance Test‐Driven Development (ATDD) where the criteria or requirements specified by the customer are automated into acceptance tests, which then drive the traditional unit Test-Driven Development (TDD) process.

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

Many code metrics have synonym as following:
Lines of Code (LOC): Source Lines of Code (SLOC)
Class Coupling: Coupling Between Objects (CBO)
Depth of Inheritance: Depth of Inheritance Tree (DIT)
Efferent Coupling (Ce): Outgoing Dependencies
Afferent Coupling (Ca): Incoming Dependencies
Cyclomatic Complexity: Program Complexity

Strategic debt: Debt caused to gain strategic benefits (such as time to market)
Tactical debt: Short-time gains, for instance cutting some corners to make an extra release for increased customer satisfaction
Inadvertent debt: This is typically caused by a lack of awareness or knowledge
Incremental debt: Caused by repeating the above without any work to reduce the debt

The Scrum Team has Focus on what is most important now without being bothered by considerations of what at some point in time might stand a chance to become important. In addition, the Scrum Team shows Respect for stakeholders by not building features that nobody will use. Finally, the Scrum Team shows Courage by not building stuff that nobody wants.

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.

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

Mock objects are used to simulate the behavior of a given object in order to cope with dependencies and isolate the system under test for controlled testing. For more information, it is possible to use the TDD approach without mock objects.

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. It includes the following principles: Single responsibility principle, Open-closed principle, Liskov substitution principle, Interface segregation principle, and Dependency inversion principle.

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.

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.

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.
In addition, there are no special Sprints in Scrum such as Hardening Sprint, Stabilization Sprint, and Refactoring Sprint …

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.

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

The KISS principle states that most systems work best if they are kept simple rather than made complicated. It is explained as “Keep it simple, silly”, “keep it short and simple”, “keep it simple and straightforward”, “keep it small and simple” and “keep it stupid simple”.
In addition, Simplicity should be a key goal in design.

Developers are responsible for doing all the required tasks to create a potentially releasable Increment. Writing tests as same as other tasks is a part of the development. On the other hand, there is no title among Developers such as QA specialist, tester, or coder, but all members are a developer. 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.

Scrum is based on an adaptive approach and the Team inspects and adapts itself continuously as they learn more about the product and development process. During the project, the Team may encounter many problems, issues, or improvements so they could adapt, change and improve themselves whenever needed about everything such as practices, tools, or techniques.

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.

In addition, there is no special Sprint in Scrum such as Hardening Sprint, Stabilization Sprint, or Test Sprint …

YAGNI means always implement things when you actually need them, never when you just foresee that you need them. It is a principle behind the XP practice of “do the simplest thing that could possibly work.”
It stands for “You aren’t going to need it“, “You ain’t gonna need it.”

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.

Black-box testing is a software testing method in which the internal structure/design/implementation of the item being tested is not known to the tester. Also, it implies testing, either functional or non-functional, without reference to 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 black box; inside which one cannot see.

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.

A software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is generally divided into three main categories: creational design patterns, structural design patterns, and behavioral design patterns.

The Definition of Done is a shared understanding of what done means and guides the Developers in knowing how many Product Backlog items they can select during a Sprint Planning. Note that satisfactory tests for each PBI are named acceptance criteria that passing it could be one part of the Definition of Done.

According to the Scrum rules, there are just three accountabilities in a Scrum Team as the Scrum Master, the Product Owner, and the Developers, and nothing else. The project manager’s duties are distributed among three pre-defined Scrum accountabilities.

A high-performance Scrum Team lives the Scrum Values deeply. Mistakes are mandatory and when they are made, they are celebrated. There are many constructive conflicts based on trust in the Team. Instead of living by the rules, they make the rules. They help their customers become more successful. The Team can release the Increment with just one press of a button through an automated continuous delivery pipeline. They evolve DoD (Definition of Done) over time and add more stringent criteria to it continuously and adhere to it completely. Almost every Sprint, the Team reaches the Sprint Goal and sometimes they exceed expectations. You can obviously see a high level of creativity, productivity, and accountability in the Team. Members are highly knowledgeable, autonomous, and self-organizing and use continuous improvement in all aspects of their processes and environment.

On the other hand, if a Team accepts other top managers’ work, they interrupt their focus and do not know if they are creating a valuable output for the customer or not. The sole source of the Developers’ work is the Product Backlog and its owner is the Product Owner. Therefore, they should refer the top managers to the Product Owner.

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.

On the other hand, although in all situations, all Team members should collaborate with all other organizational functional units or departments, it does not mean cross-functionality.

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.

On the other hand, assigning value to the Product Backlog is the Product Owner’s responsibility, and removing impediments is generally the Scrum Master’s responsibility.

The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, smaller teams communicate better and are more productive. Too few members decrease interaction and results in smaller productivity gains. Smaller Teams may encounter skill constraints during the Sprint, causing the Team to be unable to deliver a potentially releasable Increment. Too large Team requires too much coordination. Large Teams generate too much complexity for an empirical process to be useful.

The Developers do PBIs estimation after clarifying with the Product Owner. In addition, the Developers estimate tasks because they know best how to convert the Product Backlog into the releasable Increments.

The Scrum Team is self-managing so it could make decisions about adding or removing members. In fact, they are the start point of making decisions for adding or removing members. However, each organization has its own process for adding or removing the Team members that is triggered by the Scrum Team. In addition, sometimes removing a member could be converted into an impediment. In such a case, the Scrum Master can intervene to help the Team removing that person.

The Developers are self-managing which means they manage all required work to implement and convert the Product Backlog into the releasable Increments without receiving orders from outside the Team. In addition, the Developers know best how to create usable Increments.

The Product Owner is responsible for maximizing the value of the Developers’ work and changing the Sprint Backlog items in the middle of the Sprint may endanger the Sprint Goal and interrupt the Team’s focus. So, in this case, the Developers should inform the Product Owner so that s/he can work with the ones who have ordered unplanned work.

The Developers try to produce a done usable and potentially shippable and releasable Increment and piece of working software in each Sprint.

Scrum is based on the agile mindset so collaboration is the most important thing that can help the Team to increase transparency. Also, effective collaboration needs a common language. In addition, having a Definition of Done is another important thing that can increase transparency. Furthermore, there are other things for increasing transparency but these are most important.

On the other hand, the best shape of communication is face-to-face conversation. Other tools can just help and are not a replacement.

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.

The Sprint Planning time-box is at most 8 hours for one-month Sprints and usually shorter for shorter Sprints.

In Scrum, there is no dependency on the Team size for all events’ duration.

Participants of the Daily Scrum are all Developers. Others can attend for listening and observing but cannot participate actively.

Nothing. There is no special time between two Sprints and new Sprint starts immediately after the conclusion of the previous Sprint.

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

Daily Scrum is a mandatory event of Scrum and is a feedback loop that the Developers synchronize their work daily and monitor progress toward the Sprint Goal. It should be conducted every working day during the Sprint.

Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month. When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase. Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame. Each Sprint may be considered a short project.

There are many activities in Product Backlog Refinement as follows:
• Breaking down the huge items (Epic)
• Creating new items
• Removing items
• Adding detail to the items
• Analysis
• Design
• Estimation
• Valuation
• Ordering

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

When the Developers are in the middle of the Sprint, they could not change the Sprint Backlog items by themselves. If they find they have overcommitted, they should inform the Product Owner to review the items together and negotiate the scope if necessary or they might leave the Sprint Backlog intact that may lead to some undone items at the end of the Sprint, which naturally will move back to the Product Backlog.

In addition, extending the Sprint duration in the middle of it is forbidden. Also, it is not an acceptable reason for the Product Owner to cancel the Sprint. Finally, adding new members makes a short time reduction in Team performance so cannot be a proper policy.

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

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog Items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how) and is created during the Sprint Planning. The Sprint Backlog is a plan by and for the Developers.

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.

Outputs of the Sprint Planning is the Sprint Backlog which itself contains the Sprint Goal, selected Product Backlog Items, and their related tasks. The Sprint Goal is created by all Scrum Team members’ collaboration. 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.

During the Product Backlog refinement, Items are expressed with more details and broken down to the smaller Items that can be finished in a Sprint. In addition, more effort will pay to refine Items on top of the Product Backlog because they have more probability to be implemented in the upcoming Sprints so usually PBIs on top of the Product Backlog are smaller than PBIs in the bottom. Further, the Developers select Items for the Sprint from the top of the Product Backlog. Consequently, the average size of the Items in the Product Backlog is usually larger than the size of Items in the Sprint Backlog.

According to the Scrum Guide 2020, Sprint Backlog contains three elements: Sprint Goal, Sprint Backlog Items, and Tasks. As you can see, the Sprint Goal is one of the Sprint Backlog elements which is created by the whole Scrum Team collaboration. So, because of that, we should say Sprint Backlog is created by the Scrum Team during the Sprint Planning not before or after it.

Finishing Product Backlog Items is an important concept in Scrum. It emphasizes that all Team members should have a common understanding of done. Therefore, Definition of Done is introduced as part of the Scrum and defines all required work that should be completed before an end user be able to use the product and nothing else remains before its release.

Although the Product Owner approval could be required, it does not mean the PBI completeness. As a tip, the Product Owner approval would be a criteria in the Definition of Done. Furthermore, approving PBIs’ completeness is not the Scrum Master’s responsibility. In addition, there could be many things in the Definition of Done that customers do not know about such as code quality metrics’ thresholds, so customers also could not determine PBIs’ completeness. Finally, the Developers’ agreement is not enough about an Item’s completeness because they may forget to do some tasks for having a usable and releasable feature.

Done or completeness of a PBI 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

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.

When multiple teams work on the same product, one main subject is minimizing or removing dependencies among teams. Dependencies make a challenge for all teams’ outputs integration. The next subject is teams’ outputs integration, which means how teams can collaboratively create an integrated releasable Increment at the end of each Sprint.

On the other hand, teams’ utilization is not important as long as the teams deliver products to the customer continuously. Also, teams in scaled Scrum can have different durations for Sprints.

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.

The Developers in Scrum are self-organizing and self-managing, so based on knowing the product and its vision, they should decide how to divide themselves into multiple teams. Moreover, nobody else such as the Product Owner, the Scrum Master, or top management should make this decision.

In addition, they should consider each team should be cross-functional which means each team should have all required skills to convert Product Backlog Items to a releasable Increment. Also, they should adhere to the recommended size of each Team.

Furthermore, based on the situations, Teams’ compositions can be changed after each Sprint if needed.

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