PSM I Mocktest

The Product Owner is responsible for getting buy-in, understanding the stakeholders' concerns and goals. The Product Owner communicates and represents the desires of the client.

The Product Owner is responsible for measuring project performance. The Development Team only measures the performance of the current 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.

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.

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

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

Only members of the Development Team create the Increment and are the best suited Scrum Team members to do estimations. The Product Owner and the Scrum Master can suggest and use techniques to help the development team to measure their effort, however, only the Development Team does the estimation itself.

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

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

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.

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.

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

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 Scrum Theory Pillars named in the Scrum guide are Transparency, Inspection, and Adaptation. The Scrum values are Commitment, Courage, Focus, Openness, and Respect.

The decision on the order of items can be influenced by a committee, the customer, or any other stakeholder, but only the Product Owner decides what makes the most sense to optimize the value of the work being done by the Development Team.

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.

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.

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.

Scrum doesn't describe any detailed step, and rather than a methodology is a framework.

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.

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

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.

Every team tends to learn more and mature during the project, so the techniques, expertise, skills and methods improve too. This must impact on the definition of done. All Scrum roles, events, and artifacts are necessary and shouldn't be omitted for any reason

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

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.

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.

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

The Sprint Retrospective occurs always after the Sprint Review and prior to the next Sprint Planning.

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.

The Sprint Review event is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. Attendees also collaborate on the next things that could be done to optimize value.

https://www.scrum.org/resources/what-is-a-sprint-review

When the item is complete based on the Definition of Done, therefore the real and final users can use it, which also means an Increment of working software which is potentially releasable has been created.

The Development Team is cross-functional and does the work of delivering a potentially relea sable Increment of "Done" product at the end of each Sprint. They don't use any external help. Is not recommended, nor is a good practice, for the Scrum Master or Product Owner working as developers.

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

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.