PSM I Mocktest

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.

The Daily Scrum is a 15 -minute time-boxed event for the Development Team. The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15 -minute time-box.

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

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.

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

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.

Remember that Development Team is self-organized. Therefore, It is team' responsibility to measure its own productivity and performance throughout the Sprint, figure out its own process, plan, estimate and optimize the work required for items and the Sprint Goal, and to resolve their own conflicts.

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 whole Developer Teams share the Sprint Backlog items ownership and their tasks; these tasks assigned to the Developers by themselves. Also, all members of the Developer Team share the accountability of their own tasks.

The Definition of "Done" defines what is expected as result of the current Sprint. This include (but not limited) to acceptance criteria and non-functional features. The purpose is to share the same understanding of the completed work to increase transparency.

The Sprint Goal is what defines the purpose of the Sprint. The Development Team must have present that the Definition of "Done" to create tasks, but also the description of each pulled Product Backlog items.

The agreed definition of "Done" for the Scrum Team, is used to assess when work is complete on the product Increment in order to deliver an Increments of potentially releasable functionality.

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

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

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.

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.

Explanation: The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
The purpose of the Sprint Retrospective is to:

• Inspect how the last Sprint went with regards to people, relationships, process, and tools;
• Identify and order the major items that went well and potential improvements; and,
• Create a plan for implementing improvements to the way the Scrum Team does its work.

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 trend line gives us visibility about the forecast for the finishing date, considering a constant development team $\mathrm{Ca}-$ pacity for the Sprint Backlog.

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 Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

Everyone in the Scrum Team must understand what "Done" means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of "Done" for the Scrum Team and is used to assess when work is complete on the product Increment.

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.

The duration of the meetings vary. For each week of sprint duration, apply one hour of meeting time for the customer review. For the retrospective, apply . 75 hours (45 minutes) for each week of Sprint duration. For example, a 30-day Sprint would result in a four-hour review and a three-hour retrospective.

Sprint review attendees include the Scrum Team and key stakeholders invited by the Product Owner but not business users. If PO invites them then they can be included.

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.

Nobody can remove or change the Sprint Backlog items when the Sprint Planning is finished. The only exception is when there's still time and the team has completed all items, in which scenario they will pull the next item from the top 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.

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 current Sprint continues. The Product Owner and the Development Team will review and adjust the Sprint work selected, always following the Sprint Goal.

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.

Sprint Planning is time-boxed to a maximum of eight hours for a one-month sprint. For shorter Sprints, the event is usually shorter.

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.

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

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.

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.

The Scrum values named in the Scrum guide are Commit-
ment, Courage, Focus, Openness, and Respect. The Scrum Theory Pillars are Transparency, Inspection, and Adaptation.

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.

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.