PSM I Mocktest

Without a new vocabulary as a reminder of the change, very little change may actually happen. The organization may not understand what has changed with Scrum and the benefits of Scrum may be lost. Management may feel less anxious.

The main purpose of the Sprint is to create an increment of useable, and potentially relea sable "Done" product.

Agile principles support processes which promote sustainable development, this means that every person related directly to a project should be able to maintain a constant pace indefinitely.

The infrastructure and tools are prepared gradually throughout the project, and the Sprint Goal and Definition of Done should be realistic and created accordingly.

Sprint Zero doesn ' $t$ exist in the Scrum framework and all the Sprints should be able to create an Increment of working software. The Inspections and Adaptation concepts are about making adjustments gradually through the project, this includes infrastructure and tools.

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 heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created.

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.

After the Sprint planning the items pulled from Sprint Backlog can't be changed. But the broken down tasks created by the Development Team to complete the work are always changing and adapting according to their practices, techniques, and knowledge.

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

When we have shorter Sprints, there are more opportunities to show progress, and receive feedback, validate our knowledge and therefore Adapt. So, shorter Sprints are preferred when we have higher risks.

As the average velocity is 65 and 140 story points left so PO can predict it will take 3 more sprints even if there is 25 story point variation between average and max velocity.

Within an organization a Scrum Master is accountable for maximizing how people, teams, departments and the organization utilize Scrum. A Scrum Master is accountable for the way Scrum is understood and enacted. This is a true management job, with accountability, sphere and responsibility.

We need to know when an item is really done, in other words, we share a common understanding of what means a finished job. With this purpose, we can increase Transparency when there are tests included in the Definition of "Done", which will verify how close is the work of being "complete", "potentially releasable" and becoming a real Increment usable for final users.

Also writing acceptance tests help to express many of the details that result from the conversations between customers and Scrum Teams, rather than writing long lists of "The system shall...".

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.

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

The Product Owner owns the Product Backlog and is the sole person responsible for it. The Product Owner does Product Backlog management, this includes:

• Clearly expressing Product Backlog items.
• Ordering the items in the Product Backlog to best achieve goals and missions.
• Optimizing the value of the work the Development Team performs.
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next.
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

Scrum time boxed events are not extendable, you can take the available time for some these events as maximum duration, so they can be finished earlier if everything is done, but sprint time boxes have a fixed duration, this means they cannot shrink. If everything is finished before the end of the Sprint, the Development Team will pick the next item from the Product Backlog and starts working on that.

Certainly, the Sprint Backlog contains the selected Product Backlog items but also contains the tasks for the current Sprint.

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.

If a project does not include Scrum Master or Product Owner roles, this project is not doing Scrum. Both roles can be part-time but always are performed in a Scrum project. One of the most important Scrum Master activities is removing impediments, and it doesn't matter how mature is the Development Team, its members will be always benefited when someone takes care of these issues.

One the main responsibilities of the Product Owner is to maximize the value of the Development Team's work, and he's the only one who can add new items to the Product Backlog. Even when the Development Team owns the Sprint Backlog, the members don't add items arbitrarily, the Product Owner must make sure that any new item adds value and she or he can work with proper stakeholders about it and then add it to the Product Backlog for the next Sprints. Also, the Product Owner can reject the new feature, rather than the Development Team.

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.

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

The Development Team neither analyze, design nor describe the complete architecture and infrastructure, beforehand for the whole project. Agile processes are characterized by frequent short bursts of design, just enough to reach the Sprint Goal.

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

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team and the Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. But this is a hurry situation in which the Product Owner needs support from the team.

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.

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.

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

The Sprint Review is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. During this event, the Scrum Team and stakeholders collaborate about what was done in the Sprint, so is an opportunity for inspection and adaptation.

Scrum is not a methodology or body of knowledge, is a framework. A lot of organizations start implementing Agile in a cultural context that is mostly non-Agile. This creates tensions and frictions that the teams adopting Agile have to deal with.
According to the Scrum Guide, a Sprint is a time-box of 4 weeks maximum (can be less).

Spike is a task/story aimed at answering a question or gathering information, rather than at producing a shippable product. Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a "spike," which is some work whose purpose is to provide the answer or solution.

Scrum Teams are self-organizing and crossfunctional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The individual team is highly flexible and adaptive so its not highly structured. Scrum recommends 6+ or -3 members which is not a large team.

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.

The trend line gives us visibility about the forecast for the finishing date, considering a constant development team $\mathrm{Ca}-$ pacity for the Sprint Backlog.

The Scrum Master is responsible for helping everyone understand Scrum theory, practices, rules, and values. Removes impediments (solves problems), facilitates the meetings as needed. The whole Scrum Team decides the Sprint length considering one month for the maximum duration. Tasks are assigned by the Developers themselves.

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.