Product Owner in Scrum - Notebook for PSPO I
Scrum Definition
Scrum is a framework for developing, delivering, and sustaining complex products.
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
Scrum was initially developed for managing and developing products. Starting in the early 1990s, Scrum has been used extensively, worldwide, to:
- Research and identify viable markets, technologies, and product capabilities;
- Develop products and enhancements;
- Release products and enhancements, as frequently as many times per day;
- Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use; and,
- Sustain and renew products.
Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.
When the words 'develop' and 'development' are used in the Scrum Guide, they refer to complex work including software and hardware development, development and releasing of products and enhancements, development and sustaining product operational environments, research and identifying of viable markets and technologies, and even more.
As Scrum’s use spreads, developers, researchers, analysts, scientists, and other specialists do the work. We use the word “developers” in Scrum not to exclude, but to simplify. If you get value from Scrum, consider yourself included.
Scrum Theory
A Scrum Board, User Stories and Acceptance Criteria are good practices but not mandatory parts of Scrum (they are not even mentioned in the Scrum Guide).
If two Scrum Teams are added to the development of a product that previously had only one Scrum Team,?the first team should spend time on interaction with the other teams and resolve dependencies.?In the very beginning?the productivity will decrease also because members of the first team will have to do some knowledge transfer to the new teams.
Early and frequent releases of usable increments offer more opportunities for valuable feedback.
In a nutshell, Scrum requires a Scrum Master to foster an environment where:
1. A Product Owner orders the work for a complex problem into a Product Backlog.
2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
4.?Repeat
Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value. The Scrum framework is?purposefully incomplete, only defining the parts required to implement Scrum theory. Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.
Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase.
Organizations adopting agile product delivery practices can easily lose sight of their real goal of improving the value they deliver, by focusing on improving activities and outputs instead of on business outcomes. Monitoring only the direct use of practices does not provide the best evidence of effectiveness; for example, tracking a Scrum Team's velocity says nothing about whether that team is actually delivering something that is useful to customers or users.
Burn-down chart shows the amount of work left to be done, versus the time allocated for the iteration. Burn-down charts are an efficient tracking tool, because they show when the work remaining is projected to be completed if nothing changes on the backlog or Scrum Team. The burn-down chart is a helpful tool for the Scrum Teams to self-manage BUT it is not mandatory as the Scrum Teams will decide the best way to manage their own progress and promote transparency.
Technical debt is a concept in programming that reflects the extra development and testing work that arises when 'quick and dirty' solutions result in later remediation. It creates an undesirable impact on the delivery of value and an avoidable increase in waste and risk.
Time-to-Market is a Key Value Area (KVA) of the Evidence Based Management (EBM) approach that expresses the organization’s ability to quickly deliver new capabilities, services, or products. Customer satisfaction is a Key Value Measure (KVM) under the Current Value KVA that helps gauge customer engagement and happiness with the product.
? The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.
Scrum Values
Successful use of Scrum depends on people becoming more proficient in living five values: Commitment, Focus, Openness, Respect, and Courage.
The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. The Scrum Team and its stakeholders are open about the work and the challenges. Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work. The Scrum Team members have the courage to do the right thing, to work on tough problems.
These values give direction to the Scrum Team with regard to their work, actions, and behavior. The decisions that are made, the steps taken, and the way Scrum is used should reinforce these values, not diminish or undermine them. The Scrum Team members learn and explore the values as they work with the Scrum events and artifacts. When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust.
Scrum Team
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
It's not mandatory for multiple Scrum Teams workings on the same project?in Scrum.org to start and end the Sprints at the same time. That makes it much more difficult to manage the whole project. It's not mandatory, because you may need it in certain cases: maybe some teams are working on parts of the project that need longer Sprints (four-week), while others need shorter ones (two-week) for shorter feedback loops.
The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also?self-managing, meaning they internally decide who does what, when, and how.
Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.
Scrum Teams are self-managed. The agile professionals organize themselves into Scrum Teams.
The Scrum Team consists of a Product Owner, Developers, and a Scrum Master.?
The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
The Scrum Team can meet the Stakeholders whenever they need. During the Product Backlog Refinement sessions for example…
The Scrum Team delivers an Increment of product functionality?every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it. If the Definition of Done for an increment?is?part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum.
Product Owner
The Product Owner is accountable for effective Product Backlog management, which includes:
● Developing and explicitly communicating the Product Goal;
● Creating and clearly communicating Product Backlog items;
● Ordering Product Backlog items; and,
● Ensuring that the Product Backlog is transparent, visible and understood.
As a Product Owner, releasing new features and/or functionalities every Sprint, maximizes value for your customers and users. You have to release a Product to customers/users, in order to find out if you have delivered value for them and to learn what they find valuable and feed the information into the Product Backlog.
The Product Owner is the sole person responsible for managing the Product Backlog. Therefore, he is the only person responsible for collecting feedback from the stakeholders in order the shape his product's vision.
While anyone in the Scrum Team can do the legwork at the Product Owner's discretion (by adding and ordering new Product Backlog Items for example), nobody can replace the Product Owner at the Sprint Review.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog.
There is no correlation between the amount of resources used for the product development and the product value. The product value mainly come from the Product Owner's choices along with the whole Scrum Team's quality of work.
The Product Owner may consider the dependencies between Product Backlog Items but not the dependencies of the software tools used by the Developers.
The Product Owner helps the Developers to build on the right thing (ie the envisioned Increment). The Developers help the Product Owner to make sound decisions on?what the right thing is (ie Product Backlog item) and when it should be done (ie ordering of the Product Backlog). Therefore, their collaboration must be frequent.
The Product Owner is in charge of monitoring the TCO (Total Cost of Ownership) and this entails contemplating all the investments (conception, development, operation and maintenance) to be made in the product. For example, quality impacts the TCO and life expectancy of a product. Getting software out of the door quickly with poor quality may achieve a short-term win but it incurs technical debt. The software becomes difficult to extend and maintain. This results in high cost and long lead times for new functionality. And software with poor quality often has to be replaced sooner rather then later resulting in a short life expectancy and a poor return on investment. A Product Owner is ultimately concerned with Maximizing Return On Investment (ROI), optimizing Total Cost of Ownership (TCO), and capitalizing on product Agility.
The Product Owner is responsible for the Product Backlog. Who adds the items and how they are added to the Product Backlog vary widely across organizations, Scrum Teams, and individuals.
“Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.”
Scrum Master
The Scrum Master serves the Scrum Team in several ways, including:
The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
The Scrum Master is a true leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t.
The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
The Scrum Master ensures that the Developers have the meeting, but the Developers are responsible for conducting the Daily Scrum. The Scrum Master teaches the Developers to keep the Daily Scrum within the 15-minute time-box.
Developers
The Developers are responsible for all estimates. The Product Owner may influence the Developers by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.
No one can force the Developers of the Scrum Team to work from a different set of requirements.
Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.
The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:
●?Creating a plan for the Sprint, the Sprint Backlog;
● Instilling quality by adhering to a Definition of Done;
● Adapting their plan each day toward the Sprint Goal; and,
● Holding each other accountable as professionals.
The Developers are responsible for managing and tracking the progress of their work during a Sprint.
Also, if the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
All increments to be done by the Developers must ultimately come from the Product Backlog as it is the single source of product requirement. How the work is done can change, evolve, and emerge as more is learned.
Scrum Events
All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.
Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.
Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.
Scrum events should be held at the same time each Sprint. This helps with consistency, making improvements to the process, and reducing waste. In an event that a Scrum event cannot begin at the Scrum Team's designated time, they will need to inspect and adapt the event itself in order to maximize the effectiveness of the event. Delaying events is a short-term solution and results in reducing the team's opportunities to improve.
The Sprint
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. There is no "Release Sprint".
Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.
The objective of the Sprint is to produce a shippable Increment at the end of each Sprint so that the team can effectively inspect and adapt accordingly.
A new Sprint starts immediately after the conclusion of the previous Sprint.
Frequent releases to production are good practice to get some feedback from the market. However, releasing each increment is not mandatory.
A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.
A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.
A Sprint can be cancelled before the Sprint time-box is over.?Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Developers, or the Scrum Master.
The only outcome of each Sprint is a potentially releasable Increment of “Done” product.
A “Done” increment is required at the Sprint Review.
Sprint Planning
Enough work is planned during Sprint Planning for the Developers to forecast what it believes it can do in the upcoming Sprint.
Sprint Planning addresses the following topics:
Topic One: Why is this Sprint valuable?
Topic Two: What can be Done this Sprint?
Topic Three: How will the chosen work get done?
Daily Scrum
Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Developers' level of knowledge. This is a key inspect and adapt meeting.
The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To?reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
Scrum Review
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations.?The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
A releasable increment must be delivered at the end of each Sprint. However, releasing that increment to production is not mandatory. It's done only when necessary. When it makes sense...
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
The Sprint Review includes the Scrum Team and key stakeholders invited by the Product Owner. During the Sprint Review the Product Owner: Explains what Product Backlog items have been 'Done' and what has not been 'Done'; Discusses the Product Backlog as it stands and any projections to date.
领英推荐
Scrum Retrospective
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one- month Sprint. For shorter Sprints, the event is usually shorter.
The Definition of Done doesn’t need the Product Owner’s approval.
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
The Definition of Done provides the same shared understanding and transparency of what has been done at the end of the Sprint.
The moment a Product Backlog item meets the Definition of Done, an Increment is born.
The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.
The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.
Scrum Artifacts
Product Backlog
Non-functional requirements should be worked on alongside functional development.
The Product Backlog is a living artifact that evolves and changes as more is learned.
Constant feedback loops from product users / stakeholders are necessary to updated and re-order the Product Backlog.
It's the responsibility of the Developers to estimate the amount of work of Product Backlog items and to select appropriate number of them for each Sprint. They also break down the items into tasks during the Sprint. Measuring the project performance is the responsibility of the Product Owner, while measuring the Sprint performance is done by the Developers. Creating new Product Backlog items, ordering them (prioritization) and making sure that everyone has a clear understanding of them is the responsibility of the Product Owner.
While the Product Backlog must be ordered, ordering by priority is only one many techniques. The Product Backlog indeed must be ordered: its ordering determines the Product Backlog items' (PBI) order of delivery. The Developers can discuss Product Backlog Items ordering with the Product Owner but, in the end, the Developers must take the Product Backlog Items in the Product Backlog order. However, the Product Backlog is not guaranteed to represent an ordering of PBIs by either value or priority. You can’t just assign priorities to the PBIs — whether they come from the ROI or importance to the business or anywhere else — and then prioritize the backlog on the basis of those relative values. As a Product Owner, you must consider the entire backlog of PBIs together. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Backlog can contain initiatives, functional and non-functional needs, enhancements, ideas or any other product needs.
Customer Satisfaction, Customer Usage Index, and Customer or user satisfaction gap are Key Value Measures defined in the Evidence-Based Management (EBM) approach. It is an empirical approach that provides organizations with the ability to measure the value they deliver to customers.
Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog. Also the dependencies between Product Backlog items may be taken into consideration.
A Product Backlog Item can be removed if it turns out to be irrelevant or obsolete. The Product Owner only focuses on value.
Stakeholders can be invited to Backlog Refinement sessions as needed.
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
Having a clear and inspiring Product vision helps in motivating and inspiring the people involved and affected by the product. It also provides a common understanding of the direction we are working towards. It also supports the Product Owner in making choices about what to build and what not to build for the Product.
Minimizing dependencies reduces complexity and enhances agility.
Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.
The earliest development of the Product Backlog lays out the initially known and best-understood requirements. It evolves as the product and the environment in which it will be used evolves and constantly changes to identify what the product needs to be appropriate, competitive, and useful.
The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. The Product Owner works diligently to identify these needs. The Product Owner is responsible for ensuring that the status of the project is visible, transparent, and clear to all. At any point in time, the total work remaining to reach a goal can be summed and information is made transparent to all stakeholders.
Sprint Backlog
All?Sprint Backlog Items?are “owned” by the entire Scrum Team, even though each one may be done by an individual Developer.
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Developers about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Developers about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.
Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.
During the Sprint, the Sprint Backlog can be modified as more is learned. However, no changes are made that would endanger the Sprint Goal.
Increment
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.
===================================
In project management, the Cone of Uncertainty describes the evolution of the amount of best case uncertainty during a project.
The Cone of Uncertainty describes the evolution of the amount of best case uncertainty during a project. At the beginning of a project, comparatively little is known about the product or work results, and so estimates are subject to large uncertainty. As more research and development is done, more information is learned about the project, and the uncertainty then tends to decrease.
Revenue is not the only measure of product’s value.
Users’ satisfaction is the best measure of product’s value.
As per the Scrum Guide version of 2020 : "Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal."
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, we have found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.
The Developers use the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.
The Product Backlog is a living artifact that evolves and changes as more is learned.
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.
The Developers modify the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Developers work through the plan and learn more about the work needed to achieve the Sprint Goal.
As a Product Owner, you have to find a balance in both delivering internal value and external value. Internal measures can be cost savings, FTE reductions, employee satisfaction, time spend on a certain (internal) process, revenues, etc. External measures can be customer satisfaction, NPS, etc....
The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.
The Product Owner and the Scrum Master?SHOULD?NOT?be the same person for neutrality reasons.
However, nothing says that they CANNOT?be the same person in the Scrum Guide.
That is not best practice as there would be a conflict of interest. But it is not forbidden as it can be more convenient for small teams of 4 people for example.
Everything in the Increment must be Done; i.e., 100% DONE! If an item is not done, we won't include it in the Increment and send it back to the Product Backlog.
Sprint Planning is 8 hours for a one-month Sprint and usually shorter proportionally for shorter Sprints (best practice but not mandatory).
For a 1 month sprint, the best time-box for each Scrum event includes Sprint Planning: 8 hours or less, Daily Scrum: 15 minutes or less, Sprint Review: 4 hours or less, Sprint Retrospective: 3 hours or less.
Developers are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Developers' overall efficiency and effectiveness.
The Product Owner?is responsible for measuring the progress of the project, and tracking the remaining work?in the Product Backlog.
The Developers?are responsible for measuring the progress of the Sprint, and tracking the remaining work?in the Sprint Backlog.
The Scrum Teams in a Nexus (Scaled Scrum) produce a single Integrated Increment every Sprint.
The Nexus Sprint Review is held at the end of the Sprint to provide feedback on the?done Integrated Increment?that the Nexus has built over the Sprint and determine future adaptations.
First of all, it's OK of the Sprint Backlog is not complete until the end of the Sprint. However, we would try to complete it if it's possible. When the Developers find out they are behind schedule they will ask the Product Owner for help and the two roles together will adjust the work (tasks), or reorder the times to make sure the highest value will be created at the end of the Sprint.
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
The Scrum Review is also an opportunity to collect customer / user feedback from the Stakeholders.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
The Sprint Review is the second to last event of the Sprint and is time-boxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. In other words it can be defined as the longer term consequences of poor design decisions. Technical debt is a real risk which can genuinely be incurred. It compromises long-term quality of the Product. One of the ways of handling technical debt is recording it on the Product Backlog. So, it becomes visible to the Scrum Team.
The structure of the meeting is set by the Developers and can be conducted in different ways if it focuses on progress toward the Sprint Goal.
The Sprint Review contains much more activities to inspect the Increment and adapt the Product Backlog. For example: The Product Owner also explains what has not been “Done”; The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning; Review of the timeline, budget.
A Product Backlog is never complete. The earliest development of it only lays out the initially known and best understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists.
KVA stands for Key Value Area.
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.
The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.
Scrum Masters are true leaders who serve the Scrum Team and the larger organization. The Scrum Master serves the Scrum Team in several ways, including:
● Coaching the team members in self-management and cross-functionality;
● Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
● Causing the removal of impediments to the Scrum Team’s progress; and,
● Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.
Product Backlog management 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 Developers perform;
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
Ensuring the Developers understand items in the Product Backlog to the level needed.
Not all tasks are identified in the Sprint Planning; just enough to show what the Developers are going to do in the next few days. The rest of the tasks will be created during the Sprint.
During the Sprint:
No changes are made that would endanger the Sprint Goal;
Quality goals do not decrease; and,
Scope may be clarified and re-negotiated between the Product Owner and the Developers as more is learned.
As the adding new features will endanger the sprint goal so it should be introduced
Small is not a characteristic of the product backlog; it’s a characteristic of a good user story. The acronym DEEP to summarize several important characteristics of good product backlogs: Detailed appropriately, Emergent, Estimated, and Prioritized. DEEP criteria are useful for determining if a product backlog has been structured in a good way.