PSM I Mocktest

"Won't have" - These are requirements which the project team has agreed will not be delivered (as part of this timeframe). They are recorded in the Prioritized Requirements List where they help clarify the scope of the project. This also helps to manage expectations that some requirements will simply not make it into the Deployed Solution, at least not this time around.

The Moscow method is a prioritization technique used in management, business analysis, project management, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement; it is also known as MoSCoW prioritization or MoSCoW analysis.

The term Moscow itself is an acronym derived from the first letter of each of four prioritization categories: M - Must have S - Should have C - Could have W - Won't have

The interstitial Os are added to make the word pronounceable. While the Os are usually in lower-case to indicate that they do not stand for anything, the all-capitals MOSCOW is also used.

Scrum is founded on empirical process control theory or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.

Adaptation, Transparency, and Inspection are the Scrum Theory Pillars. Scrum as Agile framework, is mainly about adaptation (instead of prediction).

Many nonfunctional features, like security, can be added as acceptance criteria and tests in the Definition of Done to be applied to all or some Product Backlog items.
We can have some specific security concerns that can be items in the Product Backlog.

The Development Team is cross-functional and self-sufficient, should be capable of taking care of every aspect of the product, including security.

Being self-organized implies that the team follows its very own process, rather than receiving orders. When it's so, the members of the team tend to commit themselves and increase their accountability, and creativity.

The Scrum Master serves the Development Team in several ways like:

• Coaching the Development Team in self-organization and cross-functionality.
• Helping the Development Team to create high-value products.
• Removing impediments to the Development Team's progress.
• Facilitating Scrum events as requested or needed.
• Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

When Product Backlog is created, items are added to it.
They have different sizes and eventually are ordered on their business value. The most valued items will be on the top and usually, these items would be broken down into smaller ones. We don't do this with those items on the bottom. That's why usually larger and less clear items are on the bottom of the Product Backlog.

Developers should be self-organized and they're responsible for team's formations and composition.

Even if the team doesn't deliver increment the Product Owner must be informed about it, and s/he must work with the Development Team and adjust, add, and/or remove Sprint Backlog Items through the Sprint in order to achieve the Sprint Goal. But, since this is still the Sprint Planning we also still have the chance to modify de Sprint Goal, we won't able to do so after the Sprint Planning.

We always work on a regular and constant pace, we shouldn't work overtime.
We shouldn't change the number of developers, adding developers won't increase productivity in short term.

The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

An effective facilitator will always agree with the process and participants of the workshop with the workshop owner before the workshop.

The Development Team is self-organized, hence its members decide on the way they work and on the technical approach of the project.

The only ones who must attend are the members of the Scrum Team. The Scrum Master ensures that the Development Team has the meeting but he doesn't need to be present at the meeting. Anyone else can attend but don't "must" be there, and notice that the guests only watch and listen they don't participate.

There's no hardening Sprint, Sprint zero, integration Sprint, release Sprint, etc. There's just one type of Sprint, and its goal is to create an Increment of potentially relea sable valuable features.

The only one who can cancel a Sprint is the Product Owner. This can happen when he realizes that the Sprint doesn't make sense anymore, because the Sprint Goal has become obsolete.

Eliminating impediments and facilitating Scrum events as requested or needed is the kind of things expected from the Scrum Master. The development team is self-organized, Scrum Master does not give them orders. The Scrum Master must ensure that the Product Owner knows how to organize the Product List to maximize value, but the Scrum Master is not responsible for doing so.

The Product Owner is the sole person responsible for managing the Product Backlog but always can and must consider the feedback and opinion from other stakeholders including the Development Team who can influence to add new items in Product Backlog. Good requirements should be brief enough, that's why acceptance tests can be used to express many of the details that result from the conversations between customers, users, Product Owners and developers, including nonfunctional requirements. One product only has one Product Backlog.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master serves the Development Team by

• Coaching the Development Team in self-organization and cross-functionality;
• Helping the Development Team to create highvalue products;
• Removing impediments to the Development Team's progress;
• Facilitating Scrum events as requested or needed; and,
• Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

The situation requires scaling of the Product Owner, but it is recommended that a single product backlog be maintained for one product, so the best option out of the above is to seek additional PO but play a lead PO and don't divide the Product Backlog as one product should have only one product backlog.

Despite the Scrum Master doesn't manage people, he manages the processes. That's why it's considered a management role. The Development Team is self-organized; the Scrum Master can coach and help but the developers are who handle the progress and performance of the Sprints. It is the Product Owner who owns the Product Backlog.

The Product Owner sets the objective that the Sprint should achieve although can be influenced by the Development Team. However, only members of the Development Team create the Increment, that's why only they pull the Product Backlog items in order to accomplish Sprint Goal.

The purpose of all Sprints is to create an Increment of "Done" work, a piece of working software usable and potentially releasable, however team doesn't need release every Sprint, but eventually, the team must release its work.

The Product Owner is responsible for measuring project performance. The Development Team only measures the performance of the current Sprint.

Scrum is especially effective in iterative and incremental projects. So product requirement changes can be easily delivered by the iterative process.

The Product Backlog items are ordered accordingly based on their business value. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. The Product Owner can consider items size and risk, but among others, these are only criteria to establish final value. Items should be independent of each other, in order to facilitate their ordering.

Every increment should be potentially releasable and completed based on the Definition of Done. However, increment doesn't have to be actually released. The Product Owner decides if make sense to release or not.

There's no such thing as Sprint zero. The first Sprint is the first one, and it's not different from other Sprints, from the perspective that the Developer Team should create an Increment. The infrastructure, tools, and requirements are prepared gradually throughout the project.

The Daily Scrum is a 15 -minute time-boxed event for the Development Team. The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting. So, it's better management not to attend.

There's no such thing as Sprint Hardening Sprint. We have a Sprint 1 , Sprint 2 and go on, a surprise additional Sprint or a planned buffer sprint is not in alignment with Agile principles of time boxed development to create a potentially shippable product. If the stories are correctly prioritized, the Definition of Done is unambiguous, and the product backlog is regularly refined based on business priorities, the teams should be able to complete the development tasks.

Development Team should try to avoid team members changes during the Sprint because it creates a short time reduction in the productivity, but if any change is a real need and the Development Team thinks this would help them to meet the Sprint Goal, then do the change.

Sprint Planning answers the following:
What can be delivered in the Increment resulting from the upcoming Sprint?

How will the work needed to deliver the Increment be achieved?
During Sprint Planning the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a "Done" product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.

User Stories, Use Cases, Tests, Tasks and even other elements which help to define and clarify the work can be part of the Sprint Backlog.

The Scrum Master serves the Product Owner in several ways, including:

• Ensuring that goal, scope, and product domain are understood by everyone on the Scrum Team as well as possible;
• Finding techniques for effective Product Backlog management;
• Helping the Scrum Team understand the need for clear and concise Product Backlog items;
• Understanding product planning in an empirical environment;
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
• Understanding and practicing agility; and,
• Facilitating Scrum events as requested or needed.

Kanban Creates Continuous Flow. In Kanban, you don't measure how much you can do within a certain period, but how long a story needs from idea to roll out. Limiting the work in progress is a major guideline, which guides you towards solving the most important bottleneck in your process first. Visualizing the process, putting your efforts on collective problem solving (swarming) and having metrics (lead times for example) and pushing you to streamline your flow: limiting the overhead in the steps from conception to production.

What is DSDM?

DSDM is an Agile method that focuses on the full project lifecycle, DSDM (formally known as Dynamic System Development Method) was created in 1994, after project managers using RAD (Rapid Application Development) sought more governance and discipline to this new iterative way of working.

DSDM’s success is due to the philosophy “that any project must be aligned to clearly defined strategic goals and focus upon early delivery of real benefits to the business.” Supporting this philosophy with the eight principles allows teams to maintain focus and achieve project goals.

Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software and higher quality of life for the development team. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development.

The purpose of the Sprints is creating increments; in other words, a piece of working product which is potentially shippable and based on the agreed Definition of "Done", regardless of the techniques, documents or methods used to achieve this.

The Scrum Master serves the Development Team in several ways, including:

• Coaching the Development Team in self-organization and cross-functionality; \- Helping the Development Team to create highvalue products;
• Removing impediments to the Development Team's progress;
• Facilitating Scrum events as requested or needed; and,
• Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Significant aspects of the process must be visible to those responsible for the outcome. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team. So having a large visible Storyboard on a wall continuously communicates progress within the team and to other stakeholders.

All these choices are correct criteria in deciding the duration of a sprint.