Guangning Yu's Blog
Home
Code
Data
Setup
Industry
MachineLearning
Archive
Notes | Professional Scrum Product Owner (PSPO) II Certification
2023-10-31 14:22:25
# Materials - [Scrum Guide](https://scrumguides.org/scrum-guide.html) - [Scrum Glossary](https://www.scrum.org/resources/scrum-glossary) - [Evidence-Based Management Guide](https://www.scrum.org/resources/evidence-based-management-guide) - [Kanban Guide for Scrum Teams](https://www.scrum.org/resources/kanban-guide-scrum-teams) - [Nexus Guide](https://www.scrum.org/resources/nexus-guide) - [Udemy | PSPO II Scrum Product Owner Certification Preparation 2023](https://www.udemy.com/course/pspo-ii-scrum-product-owner-2-certification-prep) # Notes ## 1. Introduction - About the exam - $250 USD per attempt - Passing score: 85% - Time limit: 60 minutes - Number of Questions: 40 (partial credit provided on some questions) - Format: Multiple Choice, Multiple Answer - Lifetime certification - no annual renewal fee required - Recommended courses: - Professional Scrum Product Owner - Professional Scrum Product Owner - Advanced - Practice assessments: - Product Owner Open - Evidence-Based Management Open - Scrum Open ## 2. Scrum Team - The Scrum Team consists of one `Scrum Master`, one `Product Owner`, and `Developers`. - The team should have all the skills needed to create the product. Having to rely on others outside of the team means dependencies on people outside of the team. This will result in delays. A knowledge gap affecting planning, design and architecture, creating development debt in the future. - Questions -  -  -  -  ## 3. Scrum Artifacts - The 3 Scrum Artifacts - `Product Backlog` - `Sprint Backlog` - `Increment` - Multiple Increments may be created within a Sprint. - 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. - Work cannot be considered part of an Increment unless it meets the Definition of Done. - 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. - Questions -  -  -  -  ## 4. Scrum Events - Scrum combines 4 formal events for inspection and adaption, within a containing event - `The Sprint`. - `Sprint Planning` - `Daily Scrum` - `Sprint Review` - `Sprint Retrospective` - The 3 topics in `Sprint Planning`: 1. Why is this Sprint valuable? 2. What can be done in this Sprint? 3. How will the chosen work get done? - The 3 popular questions asked in the `Daily Scrum` (not an official Scrum technique): 1. What did you do yesterday? 2. What will you do today? 3. Any blockers? - There is no Sprint 0, if you see this it is incorrect. It starts with Sprint 1 and an increment of deliverable functionality is expected even in Sprint 1! - Sprint 1 can start with a Product Vision/Goal from the Product Owner which is turned into a Sprint Goal with the Scrum Team and that is all that is needed. The Developers can then start, granted they will need to add to the Sprint Backlog as more work is discovered but this is expected. - There are no in-between Sprints, the next Sprint starts immediately after the last. - Questions -  -  -  -  ## 5. Scrum Value - The 5 Scrum Values: - `Courage` - `Focus` - `Commitment` - `Respect` - `Openness` -  - Questions -  -  ## 6. Organizational Design and Culture - Organizational Design and Culture covers the following areas: 1. Helping the organization to adopt Scrum aiming for professional Scrum 2. Helping people to enact an empirical approach for complex work 3. Helping people work in Scrum teams correctly 4. Embedding the Scrum Values - Parts of Organizational Design: - Self-Management - Cross-Functionality - Iterative Development - Inspecting - Adapting - A few points by Organizational Culture: 1. There is top-down support for the Product Owner 2. Bottom-up intelligence and decisions made on empirical evidence 3. Constant learning and iterative development from the empirical pillars of transparency, inspection and adaption 4. Try to reduce waste and be more lean 5. The Scrum team is self-managing and empowered to manage their own work 6. Within a Scrum Team, there are no sub-teams or hierarchies 7. Embedding the Scrum values across the organization - `Mechanical Scrum` vs `Professional Scrum` - [What is Professional Scrum Infographic](https://www.scrum.org/resources/what-professional-scrum-infographic) - `Mechanical Scrum` consists of going through the motions of using Scrum - `Professional Scrum` goes beyond that, changing the way that you work, think and act -  - Questions -  ## 7. Empiricism - The 3 empirical Scrum pillars: - `Transparency` - `Inspection` - `Adaptation` - [Why Experiment?](https://www.scrum.org/resources/blog/why-experiment) - [SPRINT by Google Venture](https://youtube.com/playlist?list=PLIa_HbEgsVFIvLFb6-rYsGI3CPImbU7Bn) 1. Determine the Audience 2. Work as a team to brainstorm ideas 3. Decide as a team on the best ideas 4. Create a really basic prototype 5. Present it to the audience for feedback - [How to use Paper Prototyping within your design process](https://marvelapp.com/blog/creating-paper-prototypes-with-marvel/) -  - Questions -  -  -  -  -  -  -  -  -  -  -  -  ## 8. Product Vision -  - A `Product` is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. - `Product Goal` - The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. - The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define "what" will fulful the Product Goal. - The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next. - The Product Goal should be: 1. Inspiring 2. Strategically Sound (achievable) 3. Documented (written down) 4. Communicated (tell people) - `Product Vision` - A good Product Vision communicates: - What the product will do - Who is the product for - Why the product will do what it does - Traits of a good Product Vision: - Shared (team buy-in) - Succinct (elevator test) - Product Vision Keeping up with Technology - Changes and rapid advancements in technology will provide new opportunities for solving customer problems, and make what was not previously strategically sound now achievable. - `Product Vision Board` -  -  - `Product Vision Statement` - Sprint Planning is an opportunity to remind the team of the Product Goal and devise an incremental steppingstone towards it, the Sprint Goal. - Sprint Review is an opportunity to remind the team and stakeholders of the Product Goal and Sprint Goal. - `Product Roadmap` - [Product Roadmaps - The Ultimate Guide](https://roadmunk.com/guides/what-is-a-product-roadmap/) - `The Goal-Oriented Product Roadmap` - Outlines the high-level initiatives and major milestones that need to be achieved to reach the desired goals - The roadmap typically includes a timeline, key deliverables, and strategic themes - `The Now-Next-Later Roadmap` - It categorises increments into 3 time horizons: Now (short-term), Next (mid-term) and Later (long-term) - It focuses on the immediate and near-term priorities which will have more detail, while also providing visibility into future plans - It helps stakeholders understand what to expect in the coming weeks, months and quarters - `The Story Map` - A Story Map is a visual representation of the user journey or workflow for a product - It provides a holistic view of the product's features, user stories, and their relationship with each other - A Story Map consists of user activities or epics arranged horizontally and their corresponding user stories listed vertically underneath each epic - It helps prioritize features and plan releases based on user needs and dependencies - Questions -  -  -  -  -  -  -  -  -  ## 9. Business Strategy - The Product Strategy answers the question: "How will the product succeed?" - Business Model Canvas -  - `Project Mindset` vs `Product Mindset` - The Project Mindset defines success from the "inside out" measuring things like scope, time, budget etc. leading to more people management and task management. - A Product Mindset is an "outside-in" approach using measures like user adoption rate and retention, revenue per feature, and other Key Value Measures (KVM) to actually measure the value delivered. - The Product Mindset encourages frequent releases to inspect and adapt gaining insight into the value of the Product and a focus on what the user really wants. - `Product Owner` & `Product Management` -  -  - `Product Management Vacuum` -  - The bigger the Vacuum: - The more disconnected the technology groups are from the business - The less engaged the people on the ground become - The more reliance there is on project and task management - The more hierarchies and handoffs emerge - The more complexity is introduced - The harder it is to shift directions when the business climate changes - The more "busy work" is created - The more waste and rework occurs - The less value is delivered to customers - Solutions (`the 3 Vs`): - `Vision`: A Product Owner's clear and communicated vision provides transparency allowing people to be empowered, autonomous and self-managing to work towards a clear goal. The Scrum Framework provides the boundaries, such as the time-limited Sprints and the inspection and adaption opportunities. - `Value`: For the Product Goal to be reached it needs increments of value along the way, which are stepping stones to getting to the Product Goal, like stepping stones over a river to get to the destinations on the other side. - `Validation`: - After inspecting your increment at the Sprint Review you validate your understandings and you make adaptions to the Product Backlog. This is product validation. - You also do process validation at the Sprint Retrospective. Process and product validation are the 2 core feedback loops in Scrum. ## 10. Budgeting and Contracts - `Minimal Viable Product (MVP)`: - Accurate estimates are easier to make if you have experience building the same thing, but really difficult to accurately estimate when developing something completely new. - The MVP is a version of a product or service that has the minimum set of features required to meet the needs of early customers or users. - The MVP is designed to be released quickly and at a relatively low cost, allowing the developers to gather feedback, validate assumptions and learn from real-world usage. - The primary goal of an MVP is to test and validate the product concept, gain insights from user feedback, and iteratively improve the product based on that feedback. - The Iron Triangle of Project Management -  - Contracts - `Traditional Fixed-Price Contracts`: Any changes or modifications to the requirements typically require a change request and may result in additional costs and extended timelines. - `Agile Fixed-Price Contract`: The contract includes provisions for management changes to the requirements and scope. Changes can be accommodated within the overall budget and timeline, typically through the prioritization and reprioritization of Product backlog items. - `The Time & Material Contract`: In a Time & Material contract, the client pays for the actual time and materials used by the service provider or contractor. The contract has agreed upfront hourly rates of developers and agreed costs of materials/tools. Tracking time spent and materials used results in known costs. - Questions -  -  -  -  ## 11. Product Backlog Management - `Product Backlog` - In Scrum, the Product Backlog is the plan for the product. - Product Backlog is an emergent, ordered list of what is needed to improve the Product. - Product Backlog is the single source of work undertaken by the Scrum Team. - The Product Backlog should be transparent to all Scrum Team members and stakeholders. - `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. However, this often varies with the domain of work. - `Product Backlog Management` - For `Product Owner`: - The Product Owner is accountable for Product Backlog Management. - The Product Owner orders the items in the Product Backlog to maximize the value of the product. - While ordering, the Product Owner considers value, risk, cost and dependencies. - It is a myth that the Product Owner has to write all items in the Product Backlog. The Product Owner may choose to delegate but still remains accountable. - The Product Owner may influence the Developers by helping them understand and select trade-offs. As the Product Owner should have the best view on what is actually valuable. - For `Developer`: - The Developers who will be doing the work are responsible for the sizing. - Scaling Scrum with `Nexus` 1. There is always one Product Backlog per product, even if there are multiple Scrum Teams working on it 2. There is also only one Product Owner who manages that backlog 3. There is only ever one Product Goal per product 4. The Product Owner can delegate tasks but always remains accountable 5. All Scrum Teams must mutually define and comply with the same Definition of Done 6. When scaling Scrum identifying and reducing dependencies between the teams becomes really important. Removing dependencies in the Product Backlog is really important. 7. In a Nexus, the Sprint Review becomes the Nexus Sprint Review where the Integrated Increment, which is the result of all increments from the Scrum Teams, is reviewed 8. There is a Nexus Integration Team which is accountable for ensuring that a done Integrated Increments is produced at least once a Sprint. The Nexus Integration Team provides a focal point of integration for the Nexus. 9. The Product Owner will belong to the Nexus Integration Team 10. Multiple teams do not need to have the same sprint length. - Questions -  -  -  -  -  -  -  -  -  -  -  -  -  ## 12. Forecasting - `Sprint Backlog` - The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the `Sprint Backlog`. - Product Backlog items that can be done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. - The Sprint Backlog is a plan by and for the Developers. - It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. - Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. - For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. - Practices - Various practices exist to forecast progress, like: - `Burn-down Chart`: It shows the remaining work across time. The trend line is simply a forecast with current information should there be no unforeseen complication resulting in additional work, changing the scope or if the number of develper hours changes. - `Burn-up Chart`: It shows the complete work and total work. Changes in the scope are clearly seen. - `Cumulative Flows` - While proven useful, these do not replace the importance of empiricism. - In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making. - `Progress Measurement` - Progress measurement is mandatory in Scrum. We should be measuring the velocity of work for aiding future estimations. Just remember the Agile Principle "Working software is the primary measure of progress." - The velocity of one Scrum Team does not have a bearing on the velocity of other Scrum teams and should not be used as a measure to compare Scrum Teams against. Velocity is specific to that Scrum Team alone, as a way of measuring past performance to aid future forecasting of what can be done in a Sprint. - The Product Owner measures the progress of the Project once per Sprint to ensure value is being delivered (in the Sprint Review) - If the Developers do not meet their forecast for several Sprints, consider the following: 1. Talk about it in the Sprint Retrospective 2. The Product Owner should be available to discuss work with the Developers. 3. The Scrum Master could help the Developers improve their ability to forecast work. - `Cone of Uncertainty` -  - Questions -  -  -  -  -  -  -  -  -  -  -  -  ## 13. Product Owner - The Product Owner Stages -  - `The Scribe`: Someone on the technology side with little to no decision making ability, who has been tasked with capturing requirements. - `The Proxy`: Someone seen as a representative of the business like a business analyst or system analyst who is project and business minded not product minded. It is someone that collects information and can act as a gateway between the real decision-makers and budget holders. - `The Business Representative`: Someone from the business side and less technically minded. A business representative shows dedication to the product from the business but has limited autonomy over product management resulting in delays in decisions. - `The Sponsor`: Someone who spearheaded the initial business case, acquired the budget, and has the trust and the mandate to make financial and product decisions on the spot. - `The Entrepreneur`: Someone who spent their own money to fund the development of the product. They have complete responsibility for the overall product management decisions for both business and IT. - The Product Owner Stances -  - The preferred Stances of the Product Owner - `The Visionary`, clearly communicating the product vision, strategy, business goals, and objectives with all the relevant parties. A visionary Product Owner tends to focus on the future, on changing the status quo, and helping people to see what could be, instead of what is. - `The Collaborator`, engaging with and closely working together with the various stakeholders and Scrum Team(s). A collaborative Product Owner tends to support people in their own discovery process, whether it’s about defining goals, clarifying PBIs, or analysing customer needs. - `The Customer Representative` focused on helping others (Developers or others) to understand what customers need, what their challenges are, what pains and gains they have. Acting from this stance, the Product Owner tends to explain how our work affects customers, users, and business processes. - `The Decision Maker`, which helps the stakeholders and Scrum Team to keep time-to-market short, by keeping decision making time short. All sorts of decisions have to made on a daily basis. Some can be delegated to the Scrum Team or stakeholders, some the Product Owner has to take him-/herself. - `The Experimenter`, by stating a hypothesis, explaining what we know AND what we don’t know, by seeing a lot of the work we do as experiments, rather than ‘set-in-stone’ work packages. The Experimenter understands the need of trying out new things, exploring, innovating, and therefore; experimenting. - `The Influencer`, who helps the stakeholders to align around the product vision, strategy, goals, and objectives. Influencing the stakeholders and Scrum Team is a hard but very important job. The Influencer uses effective communication, negotiation, and influencing skills to get people to join the cause. - The misunderstood Stances of the Product Owner - `The Story Writer`: You know them: curved back, eyes glued to the screen, small font size, and a 14 step template in Jira. Story, check. Acceptance criteria check. Discussions with the Developers and Stakeholders lead to an updated template or a: “The details are in the ticket.” - `The Project Manager`: Everybody knows The Project Manager, also often referred to as Output Maximizer. This PO can show you amazing graphs and schedules in Jira, (s)he knows all about velocity and predictability, and maximizing output and delivering all features is their core focus. - `The Subject Matter Expert`: “Let me fill you in on how that works.” This is what the SME is all about. They are the business experts, senior users, architects, designers, or other people with expert knowledge in their field. They know all about the details and about every bug in the software or system. - `The Clerk`: “Sure, we can add that to the backlog.” It is these words we hear so often which characterize The Clerk type Product Owner. (S)he aims to satisfy everybody, the customer, the stakeholders, the Development Team, and the users. However, not making any choices nor offering any vision. - `The Gatekeeper`: “Look, I don’t have time for that now, just read my email from yesterday and pick the top stuff from the Product Backlog. Also, let me know when the first feature is done, so I can sign off on it, okay?” That is The Gatekeeper; always being the man/woman in the middle… - `The Manager`: “Are you doing fun, exciting, and innovative work today? How is everybody’s energy today? Are we all feeling well? How do you feel about your performance?” The Manager typically has many one-on-one conversations with each of the team members. - Questions: -  -  -  -  -  ## 14. Product Value - Value can be difficult to define but as Product Owners let us focus on value as: - Financial benefit (which the organization and shareholders receive) - Societal benefit (that society receives) - Customer satisfaction (customer happiness) - Employee satisfaction (employee happiness) - The 4 `Key Value Areas (KVA)` in The Evidence-Based Management (EBM) - `Unrealized Value (UV)` - `Current Value (CV)` - `Time-to-Market (T2M)` - `Ability-to-Innovate (A2I)` -  - `Leading indicators` vs `Lagging indicators` - Leading indicators are proactive to provide insights into future outcomes. For example market research, trend analysis and research and development. - Lagging indicators are retrospective metrics that measure past performance and outcomes. For example revenue per product, customer satisfaction scores, and product defect rate. - [PSPO II KVM Table](https://docs.google.com/document/d/15WQnqy4AgJOmoX8El1GIBPJ7LktPosxE2HCM_fSV7F8/edit?pli=1) - Unrealized Value - Unrealized Value reveals the potential future value that could be realized if the organization met the needs of all potential users. - Your aim to Decrease UV (future benefits) by increasing CV (present benefits) - The KVMs for UV are: - `Market share` (via Sales-Based Market Share, Unit-Based Market Share, Customer-Based Market Share, Market Research and Surveys) - `Customer or user satisfaction gap` (via Customer Surveys, Net Promoter Score (NPS), Customer Interviews and Focus Groups, Social Media Monitoring) - `Desired customer experience or satisfaction` (via Voice of the Customer (VoC) Surveys, Customer Interviews and Focus Groups, Customer Journey Mapping, Usability Testing, Social Listening and Online Monitoring, Competitive Analysis, Feedback and Complaint Analysis) - Time To Market - The KVMs for Time-To-Market are: - `Build and Integration Frequency`: The number of integrated and tested builds per time period - `Release Frequency`: The number of releases per time period, e.g. continuously, daily, weekly, monthly, etc - `Release Stabilization Period`: The time spent correcting product problems between the point the developers say it is ready to release and the point where it is actually released to customers. - `Mean Time to Repaire (MTTR)`: The average amount of time it takes from when an error is detected and when it is fixed. - `Customer Cycle Time`: The amount of time from when work starts on a release until the point where it is actually released. - `Lead Time`: The amount of time from when an idea is proposed, or a hypothesis is formed until a customer can benefit from that idea.  - `Lead Time for Changes`: The amount of time to go from code-committed to code successfully running in production. - `Deployment Frequency`: The number of times that the organization deployed (released) a new version of the product to customer/users. - `Time to Restore Service`: The amount of time between the start of a service outage and the restoration of full availability of the service. - `Time-To-Learn`: The total time needed to sketch an idea or improvement, build it, deliver it to users, and learn from their usage. - `Time to Remove Impediment`: The average amount of time from when an impediment is raised until when it is resolved. - `Time to Pivot`: A measure of true business agility that presents the elapsed time between when an organization receives feedback or new information and when it responds to that feedback. - Current Value - The KVMs for Current Value are: - `Revenue per Employee` - `Product Cost Ratio`: Total expenses and costs for the products/systems being measured, including operational costs compared to revenue. - `Employee Satisfaction`: Some form of sentiment analysis to help gauge employee engagement, energy and enthusiasm. - `Customer Satisfaction`: Some form of sentiment analysis to help gauge customer engagement and happiness with the product. - `Customer Usage Index (CUI)`: Measurement of usage, by feature, to help infer the degree to which customers find the product useful and whether actual usage meets expectations on how long users should be taking with a feature. - Ability To Innovate (A2I) - The KVMs for Ability-To-Innovate are: - `Innovation Rate`: The percentage of effort or cost spent on new product capabilities, divided by total product effort or cost (via Idea Generation, Research and Development Investment, Patent Filings, Collaboration and Partnerships, New Product/Service Launches) - `Defect Trends`: Measurement of change in defects since last measurement (via Establish Defect Categories, Record Defect Information, Analyze Defect Trends, Defect Trend Charts, Pareto Analysis, Root Cause Analysis, Regression Analysis, Track Improvement Actions) - `On-Product Index`: The percentage of time teams spend working on product and value. - `Installed Version Index`: The number of versions of a product that are currently being supported. - `Technical Debt`: A concept in programming that reflects the extra development and testing work that arises when "quick and dirty" solutions result in later remediation (via Static Code Analysis, Code Review, Technical Debt Backlog, Testing and Bug Reports, Application Performance, Effort Estimation) - `Production Incident Count`: The number of time in a given period that the Development Team was interrupted to fix a problem in an installed product. - `Active Product (Code) Branches`: The number of different versions (or variants) of a product or service. - `Time Spent Merging Code Between Branches`: The amount of time spent applying changes across different versions of a product or service. - `Time Spent Context-Switching`: Examples include time lost to interruptions caused by meetings or calls, time spent switching between tasks, and time lost when team members are interrupted to help people outside the team can give simple insight into the magnitude of the problem. - `Change Failure Rate`: The percentage of released product changes that result in degraded service and require remediation (e.g. hotfix, rollback, patch). - Questions -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  ## 15. Release Planning - [10 Tips for Product Owners on Release Planning](https://www.scrum.org/resources/blog/10-tips-product-owners-release-planning) - Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. - Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. - Questions that organizations need to continually re-evaluate for T2M are: 1. How fast can the organization learn from new experiments and information? 2. How fast can you adapt based on the information? 3. How fast can you test new ideas with customers? - Scrum Team should never release or review incomplete work. The Increment has to meet the Definition of Done. - If it does not, it cannot be released or even presented at the Sprint Review. - Instead, it returns to the Product Backlog for future consideration. - When the Sprint is over, the incomplete Product Backlog items go back to the Product Backlog for the same reasons. - The Product Lifecyle -  - Questions -  -  -  -  -  -  -  -  -  ## 16. Stakeholders and Customers - A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. - The most important stakeholders are `the users`. - Users may or may not be the customers. - For business-to-business, the customer might be the purchasing business but the product might be used by the staff, or another group. - In business-to-consumer, it is more likely that the customer is also the user. - At the end of the day, the user is the most important, if no one uses the product or service, then how can it be valuable? - Use `the Power Interest Matrix` to map stakeholders -  - The Scrum Team is responsible for all product-related activities such as stakeholder collaboration. - The Scrum Master accountabilities include: 1. Facilitating stakeholder collaboration as requested or needed 2. Helping employees and stakeholders understand and enact an empirical approach for complex work 3. Removing barriers between stakeholders and Scrum Teams - Questions -  ## 17. Exam Tips - If you see something mentioned that you haven't come across in the Scrum Guide you can be fairly sure it is a wrong answer. Such as mentioning the Program Manager or Project Office or Project Manager, user stories, estimations in Fibonacci scale, Epics, story points etc. - Be careful of words like “must”, “complete”, “total”, when the Scrum isn’t so precise. Some answers will be correct but not the “best correct” answer. If you are to pick only one answer, choose the one that is most inline with Scrum. - A common theme of scrum is to not apportion blame and to reduce or remove hierarchies, the team works as equals, empowered and self-managing. So anything that sounds like manager of staff, review or punishment isn't a correct answer. - Linked to the above point, there are no job titles and hierarchies like Architect, Tester, Lead Developer etc. So if you see any senior developer titles you can be pretty sure it is an incorrect answer, however it may mention titles outside the Scrum team like CEO. - Also, there is no overtime or hiring of extra resources to meet the goals and deadlines, the Sprint Backlog is renegotiated with the Product Owner.
Previous: No Post
Next:
A comparison of Power BI and native web tools
