Conquering Product Ownership - The No Bull Guide for Busy People [2 ed.]

Citation preview

Disclaimer The author or any organisation the author represents at the time of writing this book, is not a certifying body for any Scrum.org certifications and has no role or influence in granting any of the Scrum.org certifications. This book serves as guidance material to help readers prepare for PSPO I™ and PSPO II™ assessments. The terms Scrum Open, Professional Scrum™, Professional Scrum Master™, Professional Scrum Product Owner™, PSM, PSM I, PSM 1, PSM 2, PSM II, PSPO I, PSPO 1, PSPO II, PSPO2 etc. is the protected brand of Scrum.org. This book is neither endorsed by nor affiliated with Scrum.org. This book uses content adapted from the Scrum Guide from scrumguides.org and is under the Attribution ShareAlike license of Creative Commons.

Copyright © 2021 All rights reserved. No part of this publication may be reproduced, stored or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise without written permission from the publisher. It is illegal to copy this book, post it to a website, or distribute it by any other means without permission. First edition

How will this book help you? Whether you’re a seasoned Product Manager, Product Owner or are new to the Agile world - there’s always something new to learn. If you are looking to get certified as a Product Owner, or need a different perspective on how to handle practical product scenarios, this book will help. This is what you get: Part 1: All the Scrum basics - Whether you are new, or need a knowledge refresh, Part 1 will cover the main points about the history of Scrum, the Roles, Artifacts and Events. This part is straight to the point but comprehensive enough to update you with everything that is Scrum. Part 2: All about Products and Product Ownership What does a Product Owner do? What don’t they do? How do they get a good product out in the market? What tools can they use to help them? This part answers all these questions, and more! Not only does it cover the Product Owner fundamentals, but it includes short descriptions of business and marketing concepts that make a product succeed. This section exceeds the basics of Product Ownership - you’ll have

a good grasp of everything from product strategy to product metrics, market personas and more! Part 3: All about the action - The day to day of a Product Owner, Planning releases, Participating in Scrum Events, Managing the Product Backlog, Requirements gathering - it’s all there! We’ve even included a bonus section that goes through the most common challenging situations that a Product Owner encounters, and how to tackle them.

Reading this book will help you get through the first and second PSPO™ certifications.

Acknowledgements A special thank you goes out to the people in the Agile community that have helped write and review this book: Antony Nizamoglou Matthew Croker Ivan Traveso

Table of Contents How will this book help you?

4

Acknowledgements

6

Table of Contents

7

Glossary

11

Part 1

13

Agile and Scrum Fundamentals Chapter 1 A little background about Agile Chapter 2 Scrum Theory Transparency Inspection Adaptation Roles and Responsibilities within Scrum Scrum Master (SM) Developers Product Owner (PO) Artifacts within Scrum Product Backlog (PB) Sprint Backlog Increment The Increment

13 14 14 28 28 29 29 29 32 33 35 37 39 39 39 40 41

Events Within Scrum Chapter 3 Estimations and Velocity Part 2

42 50 50 60

Product Ownership 60 Chapter 4 61 Product Manager/ment and Product Owner/ship 61 Strategic (leading to Product Vision, Strategy and Roadmap): 65 Scrum: 66 Tactical: 67 Chapter 5 68 The Product Owner 68 A PO does not manage teams 69 Chapter 6 79 Product Vision 79 Product Strategy - How do we get there? 83 Chapter 7 88 Tools for Business and Product Level Strategies 88 Miles and Snow’s Organisational Strategies 99 PEST and SWOT analysis 100 4Cs Marketing Mix 100 Product Life Cycle Framework 103 BCG Growth Share Matrix 105 Diffusion of Innovation 108

Chapter 8 111 Product Roadmap 111 GO (goal-oriented) Product Roadmap 112 Now-Next-Later Product Roadmap 114 Product Value 116 Value Metrics & Evidence Based Management (EBM) 117 Thoughts and Predicaments 121 Digging Deeper 122 Chapter 9 127 The EBM Guide 127 KVA 1 - Time to Market (T2M) 127 KVM 2 - Current Value (CV) 128 KVM 3 - Unrealised Value (UV) 129 KVM 4 - Ability to Innovate (A2I) 131 Part 3

135

Tactical Product Ownership Chapter 10 Validation, Interaction and Feedback Loops Empiricism and Product Ownership The Product Owner Scrum Event Matrix Product Owner Relationships Acceptance Criteria and Definition of Done Chapter 11 Requirements Nonfunctional requirements

135 136 136 138 140 143 146 149 149 153

A little about User Stories 154 Product Backlog Management 158 How does this affect the Product Backlog? 160 What does “Product Backlog management” include? 161 Chapter 12 163 Release management 163 Release Planning 164 Forecasting 170 A note about Velocity: 172 Releases and Risk Management 173 Release Frequency 177 Releasing too often 178 Chapter 13 180 A PO's Tricky Situations - What to do, and when to do it 180 Credits 188

Glossary DoD - Definition of Done - A quality criteria that determines whether an increment can be released Done - Consistent with the definition of done Increment - The increment holds a number of PB items that are ‘done’ at the end of the Sprint plus the value of the increments of all previous Sprints. PB - A Scrum artifact known as the Product Backlog that includes Product Backlog Items which describe the requirements of the product PBI - Product Backlog Item PM - Project Manager PM - Product Manager PO - Product Owner Refinement/Product Backlog Refinement - the act of adding detail, estimates, and order Product Backlog items Sprint - A period of time usually one month or less during which a "Done", useable increment is created Sprint Backlog - A Scrum artifact that includes selected Product Backlog Items, plus their plan for delivery as an increment for the Sprint SM - Scrum Master Waterfall - A traditional project management process that is based on different phases

Part 1 Agile and Scrum Fundamentals

❖ Read this section if you’re unfamiliar with Scrum, or just need a recap about Scrum theory

Chapter 1 A little background about Agile In 2001, a ski-resort getaway in Snowbird Utah hosted the creation of what is known today as the 'Agile Manifesto1'. Seventeen software professionals gathered to discuss different software methodologies such as Extreme Programming, or XP in short. They wanted to share their approaches, ideas and experiences - but after discussing their interests in detail, they decided to go much further than that. They decided to write and publish a document that establishes the common ground of the software development community. The manifesto was a 'call to arms' of what these seventeen professionals believe in, but also what they oppose. The result was a set of values that went on to define the core of Agile:

"Manifesto for Agile Software Development." https://agilemanifesto.org/. Accessed 10 Jun. 2020. 1

Quoted from the Agile Manifesto: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: ● Individuals and Interactions over processes and tools ● Working Software over comprehensive documentation ● Customer Collaboration over contract negotiation ● Responding to Change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

These values sound well and good, but it is important to understand the reasoning behind these statements. The values do not mean and should not imply that processes, tools, documentation, contracts and plans are not required. They are just not meant to stand alone. These values recognise

that projects involve multiple people each having different skills and roles, that come together to achieve a goal. The manifesto recognises that what matters most should not be overshadowed by tedious processes, documents, contracts or plans.

Pick one set of values, and think if you can relate one of your previous experiences to these values. Try to understand why and how the value on the left is more impactful to the project output. The Manifesto for Agile Software Development also has twelve principles: 1. 2. 3. 4. 5. 6. 7. 8.

Customer satisfaction by early and continuous delivery of valuable software. Welcome changing requirements, even in late development. Deliver working software frequently (weeks rather than months) Close, daily cooperation between business people and developers Projects are built around motivated individuals, who should be trusted Face-to-face conversation is the best form of communication (co-location) Working software is the primary measure of progress Sustainable development, able to maintain a constant pace

9. Continuous attention to technical excellence and good design 10. Simplicity—the art of maximising the amount of work not done—is essential 11. Best architectures, requirements, and designs emerge from self-managing teams 12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

The manifesto is available online at agilemanifesto.org. It's handy to bookmark this link since most Scrum certifications directly reference it. These principles are the basis of the values, showing a scenario that boosts project success. However, in practice, these principles are far from easy to uphold, and require a learning journey that brings the organisation closer every single day. This book also includes practical “how to” scenarios that can be used in the working environment - more in Part 3 - Tactical Product Ownership.

Before diving into Agile, it’s good to understand what is known as waterfall - a traditional project

management methodology, to have something to compare with:

A waterfall is an area where water flows over a vertical drop or a series of steep drops in the course of a stream or river. They're also beautiful to look at, but if you cluelessly dive into one, there could be consequences. The waterfall methodology is a traditional approach that splits a project life cycle (i.e. the period between when the project starts and ends) into 'phases', each phase occurring once. Typically, the waterfall phase looks like this:

Each phase is only done once, and cannot start before the previous one is finished. Now let's put that

to a practical scenario and see how this could be troublesome. If a client is expecting a finished product in May and analysis was done once in January, the only time that the client can test their analysis is in April - four months into the project, after all of the development has been completed. During the testing, the client notices an error, miscommunication or simply insists that a feature needs to be changed due to new market demands and regulations. That feature is core, and impacts the majority of the software architecture. The Developers will need an additional month to change the architecture, and another to develop the feature. Blast! The software company now has to start over. Four months of sunk costs. Not only that, but the client is shocked when they are told to wait another two months to test the new feature. Why did this happen? ●

●

●

Analysis was not validated early enough. Testing only happened once, assuming that all the previous phases were done perfectly Development proceeded based on one version of design - the initial one, without it being validated No one checked with the client before the testing phase started, they placed their full trust on the analysis preparation work that was done in January

● ●

The project was not prepared for things that can go wrong since risks were not evaluated Communication between the people involved in different phases was minimal and only occurred at the points of handover

What should complex projects be prepared for? ● ● ● ● ●

People making mistakes Changing requirements and priorities Shifting technologies Delays Changes in deadlines

BUT WAIT! Here’s an important disclaimer: In some types of projects - typically simple straightforward ones that might have even been done many times before, waterfall can make sense. When it does make sense, problems are scarce and can be easily fixed - and that's fine.

Although you’re probably here because projects are complex, things go wrong, surprises happen and you want to learn what Agile and Scrum are all about.

THIS is where AGILE practices come into play. So what is the difference between waterfall and Agile? In a nutshell, it's the iterative and incremental process, that provides more opportunities to release, validate and improve:

Value delivery happens multiple times and in shorter time spans, instead of happening once after the

total cost and time investment. In Scrum, each cycle is known as a Sprint. An iterative process means that features are developed, validated and released in multiple cycles. During each cycle, feedback is communicated throughout the Scrum Team and stakeholders. Any issues found with the work being done can be surfaced earlier, allowing more time to adapt. Risks and changes are communicated more often with the client, allowing the team to become more responsive to the market. On a higher level, this is where Scrum comes in. Whilst Agile is a guideline and way of work, Scrum is a framework (that is, just one of the Agile frameworks). There are others that go beyond the scope of this book, but are available for reference:

Agile also incorporates different practices like test driven development (TDD), refactoring, pairing etc. These all support the Agile manifesto in order to produce high quality products that can be budgeted, developed, tested, and changed more easily. Now that you're familiar with Agile practices, think about how easy or difficult it will be for your organisation or team to follow it.

If you answered that it’s easy: Your organisation is pretty flexible to change, but there's always more improvement to be done.

If you answered that it’s hard: Like any other change, becoming Agile requires a transition period, a change in systems, practices and culture. In some cases, you will require buy-in or sign offs to introduce a new methodology to the company.

The definition of Scrum - summed up: Scrum is based on the theory of empiricism, which states that knowledge comes from experience and that ideas should be based on empirical evidence. It is also founded on lean thinking, to remove waste and increase focus on what really matters. To maximise knowledge and evidence, Scrum enables more points of feedback through the iterative and incremental approach. This way, validation happens more often, so if (or when) something goes wrong, the team is informed after a shorter period of time. Furthermore, Scrum incorporates checkpoints through Scrum events, thus providing multiple opportunities for teams to communicate and collaborate. Most importantly, product knowledge is continually enhanced from time-boxed

Sprints since customer feedback is obtained frequently when increments are released. When an organisation decides to adopt the Scrum framework, expectations include the following: ● ● ● ● ●

Transparent and regularly communicated risks with the client Handling client changes more proactively Decreasing non-value-added waste. Managing risk exposure through early and frequent product reviews Making funding and investment decisions based on releasing early and often to have regular Sprint outcome inspections and understand what value is being delivered through the investment

Scrum also addresses the following risks that are common to most projects: ● ● ● ●

Complexity and unpredictability of requirements Stability, sustainability and complexity of technology Working relationships and motivation of the people involved Timescale of planned work

It encompasses ideas from different schools of thought including time management, entrepreneurship and operations management - all tailored to suit complex environments.

Chapter 2 Scrum Theory There are three pillars that represent the empirical process control within Scrum theory, which are transparency, inspection and adaptation.

Scrum Pillars

Transparency The Scrum artifacts are designed to be transparent for a good reason; to allow anyone with an interest in the product and Sprint to be able to inspect, analyse and give feedback. Every single person in the Scrum Team should be able to know Why they are doing what they are doing, What impediments there are and Where they are going.

Inspection Scrum also incorporates checkpoints that give the opportunity for inspection of the process, product and anything else that can be improved. The events included in Scrum are suitable times for Inspection, where discussion and collaboration is encouraged (within the reasonable time boxes of course!).

Adaptation Through Transparency and Inspection, people are able to learn, constantly improve themselves and their contribution to the product. They are able to be more confident with forecasting their efforts and releases, and more importantly, they learn from things that went wrong to prevent them from happening again in the future.

The three pillars are the essence of Scrum, and as you continue reading, you will notice how everything revolves around these three pillars of Empiricism.

Scrum Values ●

●

●

●

Commitment - Commitment to the Sprint Goal, to the work that the Team wants to get done, to the Team, to delivering value and to continuous improvement. Following through on what you wish to achieve helps with building trust with team members and stakeholders. Focus - Focusing on one thing at a time means delivering an outcome with higher quality. Scrum does not recommend having Developers working on different products, Sprints or teams concurrently. Openness - Impacts trust between members of the Scrum Team and also between the stakeholders and the organisation. It induces collaboration and creates transparency around challenges that are met during product development. It's important for the Scrum Team to be open and honest about their tasks, accomplishments, impediments and progress. Courage - Courage to speak up, expose impediments and blockers, to remain transparent, to communicate differing opinions and ideas and to trust others.

●

Respect - Respecting and following up on the decisions that were taken as a team, respecting their estimations without pushing them to work long hours and burning out. Respecting opinions and different perspectives. Respecting colleagues and each other affects employee behaviour as a whole, builds a solid team culture and also improves employee happiness and success.

These values are not just needed in the context of Scrum, but in any functioning organisation.

Roles and Responsibilities within Scrum Scrum includes three main roles. If you plan on taking a Product Owner related certification, you might see questions that include roles like ‘Project Managers’, ‘Business Analysts’, ‘Testers’ and so on. Scrum does not formally define any of these titles.

Scrum Master (SM)

●

●

A facilitator, coach and Scrum guru. The primary purpose of the SM is to educate everyone about Scrum practices, principles and values. They are there to provide guidance and help out the Developers and PO when they get stuck with impediments.

●

●

●

They possess leadership skills, but are knowledgeable about the product environment and the market that it serves. They are change agents and are willing to push the wheel of change to continually improve internal processes. The SM can be thought of as a mini-Chief Operations Officer (COO).

Developers

●

In Scrum, the Developers are cross-functional and do not have specific roles or titles regardless of the type of work that they perform. Roles such as ‘Testers’, ‘Business Analysts’ and ‘Developers’ are not defined in Scrum. Cross-functional does not mean that everyone in the team does everything. There are still meant to be skill specialisations, the main point is that

●

●

●

the team understands the product and the development life cycle as a whole. The ideal number of team members defined in the Scrum Guide2 is 3-9 members, otherwise, there may be risks when it comes to effective communication. The Developers decide how to build the features of the product. At the end of the Sprint, they are responsible for the quality of what was delivered. The Developers are responsible for estimating items that are on the Product Backlog.

"The Scrum Guide - Scrum.org." https://www.scrum.org/resources/scrum-guide. Accessed 9 Jun. 2020. 2

Product Owner (PO) (more on the definition in following chapters)

The one and only Value Maximiser Also:

A product expert that is in close contact with stakeholders. Understands the work that needs to be done to increase product value and translates the needs of the product to the Developers. Responsible for Product Backlog (PB) management and Releases. A mini-Chief Enterprise Officer (CEO) . Even though the Scrum Guide does not specify a lot of details about the PO, the role is strongly linked to Product Management, Marketing, Business Development and to some extent, Project Management.

● ●

● ● ●

Together, the Scrum Master, Developers and Product Owner form The Scrum Team.

●

The recommended Scrum Team size is typically ten or fewer people.

Artifacts within Scrum Product Backlog (PB) The one source of truth for product requirements, planned features and their priority. These may look like use cases, user stories, tasks or any format that makes the requirement understandable. The PB is managed by the PO and is accessible by anyone that is involved or interested in the product. The PO is responsible for managing the PB, and ensuring that requirements are clearly defined and prioritised. More about the PB is available in Part 3 - Product Backlog Management . The commitment towards the Product Backlog is the Product Goal. This describes the next long-term objective for the product, which may be the upcoming goal as defined in the Product Roadmap. More about this in Chapter 8.

Sprint Backlog During the Sprint Planning event, the Developers analyse the PB and plan the features that they can develop within the Sprint to meet the Sprint Goal. When this happens, the feature details are transferred from the PB to the Sprint Backlog. The Sprint Backlog is owned and managed by the

Developers. The Developers update the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint as more is learned. It's the best source for understanding the progress of the Sprint, the features that are being worked on and how much work remains to be done till the end of the Sprint. Like the PB, this artifact is kept transparent, but is mostly accessed by The Scrum Team. The commitment towards the Sprint Backlog, is the sprint goal. The sprint goal does not change during the Sprint, as it provides a point of focus for the team. Sprint goals are meant to have just one target - not a summary of the entire backlog (it would otherwise be irrelevant).

Increment The increment holds a number of PB items that are ‘done’ at the end of the Sprint plus the value of the increments of all previous Sprints. The final say on whether an increment is ‘done‘ belongs to the Scrum Team. The delivery of the increment is an opportunity to inspect and adapt. Thus, the outcome of the increment will validate the value that it holds. The Product Owner then holds the responsibility to decide on when to release the increment.

The Increment

The commitment towards the Increment is the Definition of Done: a description that reflects the standards of the increment that needs to be complied to. More about the Definition of Done in Chapter 10.

Events Within Scrum Daily Scrum ●

●

The Developers are responsible for the Daily Scrum, deciding where and when to hold the event. The Scrum Master coaches them to own how and where the meeting is held and to stick to the 15 minute time box. The typical setup of a Daily Scrum includes the inspection of the sprint progress towards the Sprint Goal. This is a good opportunity to identify impediments and discuss the plan for the day.

●

If any impediments are identified, they are normally discussed and tackled after the Daily Scrum.

Daily Scrum Note This quick meeting helps the Developers understand what everyone is working on, which means that progress is made transparent every single day. This removes the need for extra meetings. Everyone’s contribution, delays and impediments towards the Sprint Goal are made clear.

TIMEBOX LENGTH: 15 minutes

OUTCOME: A plan and goal for the day on a Team level - this includes how the team will coordinate to achieve it.

Sprint Planning: The Sprint Planning event includes the following topics: Topic i - Defining the Why The PO explains which business objectives hold the most value and why they are needed to achieve the Product Goal. This provides a good basis to set the Sprint Goal. Topic ii - Defining the What The Developers and PO examine the PB to identify which features should be planned for the Sprint. They collaborate together to understand priorities and requirements. The entire Scrum Team will collectively determine a Sprint Goal after analysing the work needed. The Developers will discuss and estimate their effort required for each of the Product Backlog Items that they will take on during the Sprint. This is also known as the Sprint Forecast. During this part, the entire Scrum Team attends. Topic iii - Defining the How

The Developers collaborate to discuss the chosen features, to start understanding how to develop them to meet the Definition of Done and develop an increment by the end of the Sprint. The PO is not required for this part of the event, but should be reachable if questions need to be answered. ● Note that the Sprint Planning can start even if there aren’t any fully analysed and defined items in the Product Backlog. The analysis and further definition of these tasks can take part during the Sprint. TIMEBOX LENGTH: 4 hours for a 2 Week Sprint / 8 hours for a 4 week Sprint. OUTCOME: A goal for the Sprint, a set of backlog items and a plan towards achieving the goal.

Sprint Review ● ●

●

This is the third event, held towards the end of the Sprint. The Scrum Team and stakeholders (can include clients, customers, users, investors, internal stakeholders and anyone that is involved in the product development) are present to demonstrate the increment and suggest improvements through collaboration. An opportunity to inspect the increment, decide what to do next and adapt the PB.

●

●

Note that although this event is dedicated to obtaining stakeholder feedback, it is not the only point during the Sprint where feedback and communication with stakeholders is done. Continuous interaction with users and stakeholders encourages open communication and helps build customer relationships - it can be done during the entirety of the Sprint. The review is not, and should not ever be regarded as a gate to releasing value.

TIMEBOX LENGTH: 2 hours for a 2 Week Sprint / 4 hours for a 4 week Sprint. OUTCOME: Stakeholder feedback, a clearer idea of which items should be worked on in the next Sprint, an updated Product Backlog.

Retrospective : ● ●

●

The last event held at the end of the Sprint. The Scrum Team attends this meeting and inspects what went wrong and what went right during the Sprint. This event is regarded as a safe place to discuss anything minor or serious that hindered the Team’s progress. They discuss what can be improved and how to tackle the issues. Any kind of improvements apply, including individuals, interactions, processes, tools and their Definition of Done.

●

Solutions are proposed and actions to improve are addressed

TIMEBOX LENGTH: 1.5 hours for a two week Sprint / 3 hours for a one month Sprint. OUTCOME: Actionable improvements that provide an opportunity for the Scrum Team to inspect and adapt. Entire Sprint Timebox: Not longer than one month

What happens at the start of the Sprint? ● The Sprint kicks off with the Sprint Planning event, so a Sprint Goal is created and the Developers forecasts what work can be done. ● The Sprint Backlog is created. What happens during the Sprint? ● The Scrum Events take place. ● The work done is based on the Sprint Goal and Definition of Done. ● The Product Backlog is constantly refined throughout the Sprint ● The scope of the Sprint may be changed by the PO and the Developers as long as the Sprint Goal is not compromised. What happens at the end of the Sprint?

● The work done is reviewed by stakeholders and their feedback is communicated to the Scrum Team ● A “done” increment is prepared and the PO determines whether it can be released. ● The team retrospects and suggests improvements for the next Sprint

Chapter 3 Estimations and Velocity Any piece of work that is included in the Product Backlog needs to have a measure of estimated effort before development on the item begins. Only Developers (i.e. the people performing work directly on the item’s development), give the estimate based on their understanding of the item and its trade-offs. The measure need not be accurate - its main purpose is to give an indication of required effort when compared to the effort of other items (this is known as relative sizing) and not a definitive commitment. It is in the PO’s interest to take note of estimations so that they can use the data to plan releases - more about this in Release management Estimations are given when the Product Backlog is being refined and also during the first part of the Sprint Planning event. The Developers take each item, discuss it with the Product Owner, and give their estimates. Estimation accuracy depends on: ● The experience of the Developers. Having a team that has worked together before in

previous Sprints, means that they have given their estimates before, and have been able to compare their initial estimates with the actual effort that was needed. The more opportunities they had to compare their estimate, the better their new estimates. Estimates coming from newly-formed development teams can be expected to have a higher margin of error as before progressing towards a performing3 team. ●

Unaddressed Technical debt in the system. When the system is unstable or badly designed, adding and changing features often result in spending more time fixing affected components and less time working on the actual new feature. This also influences the team’s predictability.

●

Complexity. Predicting effort when using new technology or developing a significantly complex feature - especially those that require experimentation, are better handled using a ballpark figure, since the level of uncertainty is high. Methods such as T-shirt sizing (XL, L, M, S) are a good way of giving a rough effort indication in these cases. Complexity can also be present in:

Tuckman, Bruce W (1965). "Developmental sequence in small groups". Psychological Bulletin. 63 (6): 384–399. doi:10.1037/h0022100. PMID 14314073. 3

○ ○ ○ ○ ○ ○ ○ ●

Client requirements Market factors Existing system New technology Workflow Team relationships Networks of communication

Subjectivity. Optimistic estimates only consider the best-case scenario, which does not regard risks to the delivery. On the other hand, pessimistic estimates consider the worst-case scenario and can lead to inflated estimates. An informed PO will be aware of the assumptions that are taken when estimates are given. In the Release management section, the Release Burndown Chart is discussed in more detail and shows how to plot the best case and worst case scenarios in the same chart. This can give a better idea of the average overall estimates at a glance.

Methods for measuring estimates vary and Scrum does not require any specific method. Some common methods include: ● ●

Numeric Sizing / Story Points (e.g. 1 100) T-shirt Sizes (XS, S, M, L, XL XXL, XXXL)

● ●

Fibonacci Sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.) Planning Poker

The total amount of work that is done within a whole Sprint is a key metric, known as Velocity. At the end of the Sprint, the Developers will measure their velocity by adding up the estimates that were given for each item that was completed during the Sprint.

Velocity Calculation:

● ● ● ● ●

Items Done during this Sprint: Sprint backlog item 1 = 40 points Sprint backlog item 2 = 10 points Sprint backlog item 3 = 80 points Sprint backlog item 4 = 6 points Sprint backlog item 5 = 25 points Velocity: V1 = 40 + 10 + 80 + 6 + 25 = 161

Items Done during Sprint 2 : ● Sprint backlog item 1 = 40 points ● Sprint backlog item 2 = 25 points ● Sprint backlog item 3 = 80 points Sprint 2 Velocity: V2 = 40 + 25 + 80 = 145 Items Done during Sprint 3 :

● ● ● ●

Sprint backlog item 1 = 30 points Sprint backlog item 2 = 30 points Sprint backlog item 3 = 35 points Sprint backlog item 4 = 25 points

Sprint 3 Velocity: V3 = 30 + 30 + 35 + 25 = 120 Average Velocity = 161+145+120 3

𝑉1+𝑉2+𝑉3 𝑛

= 142

Eventually, having the data for the velocity of a number of Sprints, will serve as a good base to provide estimations of the team’s capacity, by considering the average velocity per Sprint. For instance, knowing that the Developers has a velocity of between 150 and 200 points, shows that a commitment to delivering 300 points during a Sprint Planning event is over-ambitious. There are a lot more metrics to consider when making such an assumption however, such as measuring the amount of technical debt, throughput and cycle time. More information is available in Chapter 9.

Although you may hear that a higher velocity is generally a good thing, there are major caveats to this statement: ●

Different teams may use different estimation measures. Team A’s velocity of 20, may actually mean more effort than Team B’s velocity of 500. It’s never sensible to compare velocities between different teams. Only compare velocity of different Sprints, within the same team.

●

If the team has actually delivered a much higher velocity than usual, consider whether quality has been sacrificed to make this delivery possible. A loss in quality can come back as a big hit to the product and manifest in technical debt, unsatisfied customers and buggy functionalities.

●

Similarly, if the team has delivered a much higher velocity than usual, consider what has been delivered in terms of business value. If the Product Backlog was poorly prioritised, then all that effort spent during the Sprint may result in very little business value (e.g. new features that the customer doesn’t really need).

●

With all this in mind, we know that more velocity is not equivalent to more value. Also:

A higher velocity is NOT necessarily a good thing. Last but not least, estimates are not meant to be precise. Estimates provide a forecast for what the Developers believe can be finished within the Sprint, not a commitment for delivery.

Scrum myths

“Scrum is ideal for all projects ”

FALSE: Scrum is best served for complex projects and helps expose bottlenecks and impediments earlier.

“The start of a Sprint can be cancelled or delayed at any time”

FALSE: A Sprint always starts exactly after the previous one ends - even if there are PB items that are incomplete or unclear there is no such thing as “between sprints” or “delayed sprints”. A Sprint can only be cancelled by the Product Owner if the Sprint Goal becomes entirely obsolete, or if the organisation’s strategy decides to change in a way that the product vision does not fall within the organisation’s future plans. When PBIs are still unclear during the sprint planning event, the Developers pull in what they think can be done, then refine and adapt

the items during the sprint. The retrospective then provides an opportunity to investigate improving refinement.

“Hardening Sprints help complete unfinished work”

FALSE: The “hardening Sprint” is not actually a part of Scrum and can actually harm progress in the long term. This kind of Sprint is one that encompasses all undone work coming from previous sprints. When this happens, it leaves an opening for work to be poorly planned and poorly developed. It also essentially minimises the number of feedback loops and lowers the number of opportunities for the Scrum Team to learn and adapt.

Part 2 Product Ownership ❖

Read this section to learn about Product Owner’s role in understanding the market, and defining the course of the product through creating Product Value, Product Strategy and evidence based metrics

Chapter 4 Product Manager/ment and Product Owner/ship The responsibilities of a Product Manager and PO overlap, especially in companies that are undergoing or have partially moved to using Scrum. The Product Manager traditionally forms part of the Marketing branch, working together with Sales and Advertising. In theory, the role is not as closely-knit to the functional areas as a Product Owner and is sometimes detached from the production itself, since it's more focused on Product Strategy and Marketing. In today’s world, the definition of a “Product Manager” role is exceptionally fluid - and changes depending on the organisation’s size and industry. Perhaps the most common definitions are features of their responsibilities, which are: ● ● ●

Product feasibility and research Product Strategy Using influence with functional areas to develop high quality products

Whilst a Product Manager role can fit in a company adopting Scrum, this role is not formally part of a Scrum Team. So what exactly, is the difference between a Product Manager and a PO? In Scrum, the ideal scenario is that one product should have one PO, who fills the entire product management vacuum. In contrast with some opinions, the role of a PO is not a level below or on par with the Product Manager, but is essentially a Scrumified version of a Product Manager - a replacement of the Product Manager that adapts to Scrum values and pillars:

Note The ideal PO is the sole responsible person for all the product management for a product, thus eliminating the need for a traditional product manager

In practice, there are many variations to this: ● ● ●

●

One Product Owner for all products One product with multiple Product Owners Product Owners doing scribe and requirement gathering while Product Managers set the business vision. A Product Owner assigned to each product, reporting to an overarching Product Manager.

These situations of shared responsibility introduce a number of issues: ●

It goes against the concept of having one person responsible for the product vision, value and product management - which reduces complexities and the need to continually re-align with others with this shared responsibility. This directly impacts the prioritisation of work that needs to be done on an ongoing basis - which is a core and delicate process that the Product Owner is accountable for.

●

Furthermore, multiple owners means that there will not be anyone that has a complete, holistic view of the product's value, vision and stakeholder validation - this easily results in increased overheads, subjectivity clashes and unclear product direction.

●

Product development can also take a bad turn if one of the Product Owners is uninformed about the features that the other Product Owner is directing. The result is potentially developing enhancements that derail the product by being incompatible with the other features - and to top things off, this could end up being made apparent during the Sprint Review, regression testing or worst case scenario after release to production.

Whilst this can sound overwhelming, it's good to know that a Product Owner can delegate work related to the day to day tactics to the Developers

Where does the Project Manager fit in? (short answer: in Scrum, they don’t.) Project Managers are responsible for planning the projects, predicting associated project risks, ensuring that the project sustains its forecasted time, cost and quality and therefore track and update project documentation as progress is made. Project managers typically know very little about

the product and do not contribute to its vision - they can also manage more than one project. Product Owners are the product and domain experts, who are focused on the product, on creating customer value and on satisfying the users’ needs, while Project Managers are solely focused on project delivery, meeting deadlines, examining remaining budgets, updating schedules and so on.

Note that Project Managers are NOT part of a Scrum team The responsibilities of a PO in Scrum include the following:

Strategic (leading to Product Vision, Strategy and Roadmap): ●

● ● ● ● ●

Understanding, researching the market and industry and assessing their appetite for a product Analysing trends for market and segment attractiveness Keeping track of existing and new competitors Analysing market threats and opportunities Understanding consumer behaviour and buyer power Determining the potential impact of substitute products or emerging threats

● ● ● ● ● ● ● ● ● ●

●

Understanding the bargaining power of suppliers Taking product decisions to increase competitive advantage Ensuring product feasibility Managing the product for customer appeal and maximising ROI New product development process decisions Negotiating product deliverables and release dates with stakeholders Understanding stakeholder needs and aligning them with the product strategy Positioning the brand, building brand equity and taking branding decisions Driving product launch or taking the decision to retire a product or feature Supporting organisation decisions on pricing, distribution channels, promotions and digital marketing Reducing technical debt and keeping it to a minimum

Scrum: ● ● ●

Supporting the Developers through product backlog refinement Involvement in sprint planning, reviews and retrospectives Contributing to the sprint goal and definition of done where needed

●

Aligning the Scrum Team and stakeholders to the product vision

Tactical: ● ● ● ●

Compiling marketing metrics for trend analysis, churn analytics etc Release tracking Compilation of user stories and acceptance criteria Analysing burn down charts and product metrics

Chapter 5 The Product Owner A commonly disputed topic is the role and responsibilities of a PO in Scrum. In order to remove any misconceptions that you may be familiar with and disassociate them from the Scrum definition, it's important to define a PO that isn’t fit for purpose (i.e. the imposter PO).

A PO does not manage teams In Scrum, the Developers are self-managing - which means that they, alone, are held responsible for deciding how the work gets done, estimating development effort and moving the Product Backlog items to their Sprint Backlog. Essentially, the PO manages the Product and prioritises the features of the product through the Product Backlog and need not inspect team productivity, or individual

members. Does the customer care about how productive Developers are, or do they prefer obtaining a high value from the product?

A PO is neither a scribe nor a proxy

What is a Scribe PO?

Someone that spends the majority of their time writing requirements, user stories and product documentation, without taking responsibility for the content and its formation. PO responsibilities for deciding priorities, creating a product vision/roadmap are decided by other stakeholders or management. The Scribe PO simply notes down their decisions without interfering, discussing or negotiating during product discussions. Why isn’t this fit for purpose? ●

The PO role gets buried down and taken over by stakeholders, endangering core product transparency and the rule for having one PO for the product.

●

The Developers may have questions about the product that the PO is unable to answer or take decisions about.

●

The stakeholder may demand feature requests that fall out of scope of the product roadmap or the organisation's objectives. Without negotiation, the product's destiny will be quickly taken over by another party.

●

The PO's role in a Scrum Team will become undervalued. Conflicting priorities will interfere

with progress towards the sprint goal. Sprint scope could become subject to derailment.

Note A PO can delegate Product Backlog management to someone that is part of the Developers, including detailing Product Backlog items, interviewing users, engaging stakeholders and analysing data. However! The PO is still accountable for anything that happens in the Product Backlog.

What is a proxy PO? Someone that spends the majority of their time repeating stakeholders/client requirements/ feedback to the Developers and repeating questions from the Developers back to the stakeholders/clients. No value is added by the

proxy, they are unable to take decisions and just act as an intermediary between parties. Understanding of the content and context could be limited since they are used to copy-pasting answers and questions from one person to the other. Why isn’t this fit for purpose? ● ● ●

There is no Product Ownership, only echoing of information The importance of the product vision is diminished They are seen as an unnecessary gateway to the parties that actually hold the information that is needed

A PO is NOT a Project Manager Note that when you see the words 'Project Manager/Management' do not associate it with Scrum. As discussed earlier, Project Managers are NOT a part of Scrum. Although they probably do exist in your organisation, a PM's role is normally disconnected from the product itself.

So… What is a PO? A PO IS:

●

A value maximiser: This is perhaps the key default and important definition that you will see in most material for Scrum.

●

The sole owner of the product: Multiple POs for one product is a common anti-pattern Being responsible for part of the product, a subset of the system, a set of features or architectural layer does not comply with the Scrum definition of a PO. It is possible, but not ideal, to have one PO for multiple products.

●

In 100% control of the Product Backlog (PB): Complete responsibility of the PB rests on the PO's shoulders. They can change it whenever they need to to uphold transparency and ensure clear descriptions of stories and features. This is their primary tool that reflects the future of the product. Anyone in the organisation that is interested in the product should be able to look at the Product Backlog and have a clear snapshot of the priorities and planned features of the product.

●

A PO decides What the product is and Why it's there, but does not decide How to develop it. They decide what needs to be implemented and at what priority, they have a complete

understanding of the importance of the feature, the need it satisfies, the value it holds, the risks it carries and the impact on the product's future. The PO however, trusts the Developers to build and develop these features as they deem fit (as long as they meet the respective acceptance criteria). While a PO has every freedom to make suggestions, he/she does not hold the final say on how to develop or implement a feature. A PO can decide the “how?” on a strategic level (only) - for instance, how to make the product more competitive? How to engage customers? How to ensure regulatory requirements are met? ●

A product and customer expert: Well-informed about the product's current and future markets, the product's competitors, user habits and psychology. They know the product's history and are capable of building a solid path towards its future. They know the necessary ingredients to develop the product, grow it, and shield it from competition. They are up to date on current technology trends and habits related to the product. They understand what influences the product from an economic, compliance, regulatory, financial and social point of view. They understand all dependencies and interdependencies of what it takes to build the product, the knowledge and resources required

(e.g. technical knowledge, business domain knowledge, PR knowledge etc). They might not be deeply technical - but can understand what knowledge is required to actually build and release the product successfully. ●

An entrepreneur, experimenter and visionary: POs are naturally business-minded and driven. They are good negotiators and can spot profitable business opportunities and investments a mile away. They know what it takes to keep customers happy through high product value and reduced waste. They will take calculated risks to hold experiments for their ideas, even if they have limited resources. They are innovative in recognising market opportunities and driving competitive products to success, ensuring a right Product-Market fit. They visualise a successful product, help people understand its future potential and are able to see it through. You will typically recognise this in a good PO because they have probably run a business before, or are running one (or more) on the side. They have an understanding of waste reduction, investment strategies, marketing and leadership.

●

A collaborator and influencer: POs make time for the Developers to provide product guidance and explain the underlying

product rationale. They are skilled negotiators and thrive to align anyone involved in product development to the product vision by ensuring that the product’s future is kept in scope. ●

Empowered with decision making: Decision making is part of the PO’s day to day. In practice, these decisions have a direct impact on the outcome of the product and its time to market. The Scrum Team and stakeholders need the PO to be able to make informed, evidence-based decisions in a short amount of time, without creating dependencies or long delays. For the Product Owner to succeed, their decisions must be respected by the entire organisation.

REALITY: The ideal PO is a rare breed, but they should always develop themselves towards this ideal state.

Chapter 6 Product Vision What defines a product? A product is anything that can be delivered to a customer that satisfies their want or need when consumed, used or acquired. Conceptually, products include objects and services that solve problems because of the benefits they provide and the value that they deliver through product features and attributes. Behind each product is its producer who gains from delivering the product through increased profits, ROI maximisation, reaching corporate objectives, company growth, customer retention, increased share prices and so on. In Scrum, products are managed as independently as possible, each having their own separate release plans - so a 'product' consists of something that is packaged independently to reduce complexities and risk.

What defines a product’s vision?

A key responsibility of the PO is the communication, accountability and maintenance of the product vision.

Product Vision Characteristics A Product’s vision can only follow through if the value it will deliver is evident and if it promises meaningful impact ❖ It identifies the target user or client ❖ Establishes the core product features A Product’s vision can only follow through if it aligns with the product and business strategy ❖ It is a baseline of the Product Strategy ❖ It is consistent with the company values A Product’s vision can only follow through if the team and stakeholders believe in it ❖ Best developed through collaboration with the Scrum Team and stakeholders ❖ Has the approval of all stakeholders ❖ Allows team members to understand the clear relationship between their daily

activities and how it contributes to the product's future. Each person involved in any way can understand their impact on the bigger picture. Thinking about how each person's involvement makes a contribution towards this, will empower them to take the right decisions that are kept in line with the product vision. An engaged team and common understanding helps manage scope creep and product risks, without deviating away to something that could hurt the product's future. ❖ Serves to guide the team(s) and inform them and the stakeholders about the product's goal ❖ Serves to align, motivate and create focus through ubiquitous language ❖ Most of all, needs to be understandable and frequently communicated A Product’s vision can only be followed through if it remains relevant ❖ Evolves and changes as more is learnt from customer feedback. Think about this as a 'pivot' situation that occurs with most start-ups. Initially, a product offering starts with the intention to serve a particular

goal, and sometimes finishes with a completely different goal to better serve its users ❖ Makes it easier to inspect progress

Note The Product Vision is the face of the product’s future. It is what people look at to understand why the product is being pursued and what value it promises to provide.

Fowler 4 gives a great example template on what a Product Vision should portray ❖ For [final client], ❖ whose [problem that needs to be solved], ❖ the [name of the product] "Write the Product Vision - Martin Fowler." 5 Apr. 2017, https://martinfowler.com/articles/lean-inception/write-pro duct-vision.html. Accessed 2 Aug. 2020. 4

❖ ❖ ❖ ❖

is a [product category] that [key-benefits, reason to buy it]. Different from [competition alternative], our product [key-difference].

Product Strategy - How do we get there? Product strategies will greatly depend on the type of product and market that is being operated in. For instance, take a niche, one-of-a-kind item that has been developed through gaining intellectual property as an example. Pioneering organisations can benefit from capitalising on the early advantage. However, having an innovative product could be subject to takeover by companies that can quickly copy and produce it for less. In another scenario, the product could be a long-term bespoke service that is customized per client. The benefits that the consumers would obtain are specifically tailored to their needs, providing an opportunity to build rapport and gain a good foothold on target clients. Obtaining initial client trust may pose as a challenge without the right promotion in place. There are critical questions that need to be answered before and during a product’s

development journey. The following list is extensive, but covers a good number of points to consider before and during product development. Product Concept: ● What core benefits will the product provide? How can the product be differentiated from other similar products in the market? ● What key features will the product consist of? ● What kind of packaging and warranty will it include? ● What auxiliary services will it have (maintenance, training etc)? Pricing: Comparing investments and pricing strategies against the value delivered gives information that can be used to refine future investments. ● What is the revenue objective? When is the product expected to break-even? ● What is the estimated demand for the product? ● How sensitive is the product’s demand? ● How do the product costs and prices compare with its competitors? ● Can costs be reduced without sacrificing quality? ● How do competitor prices differ in different geographic regions? ● Can the customer’s perceived value be used as a guide to price the product?

● ●

Can discounts and offers be used to encourage demand? Can there be economies of scale to benefit from?

Distribution ● Which channels of consumption will be used for the product to reach the consumer? ● How can the product reach the consumer in a more convenient way? ● How many institutions are involved in the delivery of the product? (e.g. The product could be sold through an online platform, or could be stored in a third party’s warehouse) ● Do the values of the retailer match the values that the product portrays? ● If a third-party ecommerce website is used to sell the product, can the product’s sales be impacted by poor website user experience? ● How many different platforms should the product be shown and sold in? ● Does a sole product platform lead to too much reliance on one platform? Promotion ● How can the organisation’s branding support the product’s promotion? ● Which promotion channels are ideal and effective?

● ● ●

What kind of promotions will ensure customer loyalty? Does the product depend on word-of-mouth advertising? How can each promotion be developed to remain ethical, reflect good taste and values?

Customers & Market ● What is the target market of the product? ● What is the product’s customer persona? ● What is the expected consumer behaviour of the targeted customer persona? ● Will consumers have high switching costs if they switch over from a competitor’s product? Suppliers & key partners ● Who are the key suppliers and partners and how much do we depend on them? ● What kind of relationship is held with them? ● What are their long-term plans and how can they impact the product’s development? ● Who are the supplier’s key contact people and what could happen if they do not remain in their current position? ● Are there bottlenecks in the suppliers’ delivery that impact the product’s development? Resources and Team ● What kind of equipment, tools and licenses are needed to develop the product?

● ●

●

What are the skills of the product’s key personnel? Can a learning path be planned for team members who wish to develop existing or new skills? How can Team happiness be improved?

Risks, external forces and contingencies ● Is the product dependent on external events such as weather, fashion or season? ● How are competitors innovating and how fast do they respond to consumers? ● Which consumer trends could impact the product vision? ● What shifts in technology could benefit the product? ● Does the product have any regulatory or legal requirements?

Chapter 7 Tools for Business and Product Level Strategies Strategies can be made at different levels and contain specific focus points based on the product and its environment. They are shaped by consulting several frameworks and tools to obtain a solid starting point. This section explains a collection of tools that have been built by strategic thinkers and marketeers.

Consumer Behaviour If product value is mainly derived from its consumer perceived value, then gaining an understanding of current and potential consumers is needed to make product decisions and prioritise items in the product backlog. Creating a ‘persona’ for the target customers of the product helps with: ● ●

Understanding the needs of specific groups of users Creating a hypothesis about the product’s future value

● ● ●

Better understanding of the product’s Unrealised Value Analysing what are customer “no-gos” Understanding which features are valued the most

As the product begins to be adopted by more and more consumers, divisions may surface between them, creating groups of users, and thus, more personas. Identifying these personas may provide an opportunity to create specialisations or different versions or advertising for the product that appeals more to targeted groups. This can be achieved through consistent direct communication with end users.

Case Study: Target’s customer targeting 5 : Large retail outlets often collect data about their consumers in order to create a targeted advertising plan. Analysing a user's purchase history, product views, time spent on the organisation’s website or store, reveals attributes that are useful to marketeers. In the field of Data Mining, a task called ‘clustering’ effectively splits user data according to their attributes, creating different user profiles for the organisation to deliver their products to. More prediction techniques

are

"How Target Figured Out A Teen Girl Was Pregnant Before Her ...." 16 Feb. 2012, https://www.forbes.com/sites/kashmirhill/2012/02/16/howtarget-figured-out-a-teen-girl-was-pregnant-before-her-fat her-did/. Accessed 8 Jun. 2020. 5

also being used in the field of Machine Learning, using sophisticated algorithms to analyse historical patterns and predict user behaviour with more accuracy. In 2012, the large retail corporation Target developed a method that could identify whether a buyer is expecting to have a child in the coming months. They could also predict the mother’s due date, and were using this information to send coupons for products related to the specific stages of pregnancy. Whilst this method was effective at getting parents to-be to buy more of Target’s products, one man, a father of a highschool girl, was quite unhappy. Barging into the store, he demanded to know why the company was sending his daughter pregnancy product

coupons, and whether they were trying to persuade her into having a baby. Shocked, the Target employee apologised. A few days later, the employee called to apologise again, and the father revealed, after having a chat with his daughter, that she was hiding the fact that she was pregnant. This story says a lot about how precise customer targeting can be, however POs need to remain mindful about qualitative customer factors such as privacy, values and ethics.

Business Model Canvas The Business Model Canvas is typically used in startups to document new proposals or initiatives. It consists of a sectioned template and is designed to get people to discuss, think and describe the following business features: ● ● ● ● ● ● ● ●

Key partners Key Activities Key Resources Value propositions Customer relationships Customer Segments Channels Finances (costs/revenue)

Remember that:

POs are entrepreneurial and experiment with new product propositions. This framework can help with drafting product ideas.

Pros: ● Can be quickly drafted

● ●

Provides holistic overview of business building blocks Easy to use in a team-based hands-on workshop

Cons: ● Very high level and should not be used as the final strategy, but as a starting point ● Leaves out the planning/roadmap aspect in terms of timelines

Porter’s 5 competitive forces6 Competitive forces depend on the product and industry and explain why some products can be consistently more profitable than others. As value maximisers, POs require a good level of understanding of the market forces that can impact potential product value.

"Competitive Strategy, by Michael E. Porter. New York: Free ...." https://www.jstor.org/stable/258056. Accessed 1 Jun. 2020. 6

Threat of new entrants: How easy is it for potential competitors to emulate the product offering and compete with the product? Can the knowledge and resources to develop the product be obtained easily? If the product offering has strong cost advantages or specialised knowledge, these can serve as barriers to entry for new competitors and thus help defend its position in the market. Threat of substitute products: In the field of economics, the utility theory describes how logical consumers demand goods and services based on the utility function that represents individual preferences beyond the explicit monetary value of those goods or services. It calculates how much someone desires something, and it is relative to different choices. Consumer behaviour in economics is based on the following problem: "As a consumer, how should I spend my money in order to maximise my utility?" . In the context of product value, consumers seek to maximise the product value they get, for every dollar they spend. Therefore, if a product’s value per dollar of its price is too low, consumers will simply switch to an alternative that yields more value to them per dollar. Substitute products are any other products from a different industry that can satisfy the same

customer need. If these products exist, then changes in their price can influence the demand of the product offering, since consumers may find it easy to switch between these products. For instance, consumers may replace coffee with an energy drink, even though they belong to different industries. Since they both satisfy the consumer need of providing caffeine and energy, consumers often substitute one with the other. Bargaining power of suppliers: Suppliers may be a hidden driving force of the market, especially if supply is limited. Obtaining resources at a low cost may be the key to having a profitable product. Bargaining power of buyers: Sometimes, buyers can easily influence the product delivery and its competitiveness to favour them. For instance, if switching to a competitor is an easy, low-cost option, they can threaten to take their business elsewhere, unless product quality increases, or cost decreases, or both. When buyers are few and large, they may have more leverage and negotiating power over the product’s future. Another consideration is the threat of backward integration, that is, having the buyer develop the product themselves, alleviating the need for them to demand the product elsewhere.

Rivalry among existing competitors: Attractive investment opportunities may lead to a tightly competitive market, especially if the product is highly profitable. This may mean that customers can more easily decide to replace one product with the other and may be a risky initiative if there is little product differentiation (i.e. distinguishing product features that make it stand out from its competitors).

Miles and Snow’s Organisational Strategies In order to survive, companies need to continuously evolve, which means that their market position changes constantly. The roles undertaken by the decision makers of the company depend on the stage of the company’s evolution. In 1978, Miles and Snow identified four categories that define organisational strategy, structure and process, that are derived from a company’s decision making. They argued that the way a company tackles their problems results in them pursuing generic strategies that are categorised below: The Prospector is primarily concerned with the identification of new market opportunities and creates more focus on this rather than improving internal processes. The Analyser is characterised by sophisticated internal information systems and detailed investigation of options, but this is unlikely to be followed up by the type of action undertaken by the Prospector. The Defender is concerned with maintaining the current market position without exhibiting a great

deal of initiative opportunities.

in

developing

new

market

The Reactor simply deals with circumstances as they arise, without any clear strategy or way forward.

PEST and SWOT analysis Some more tools that aid in analysing the environment for a product include SWOT (Strengths, Weaknesses, Opportunities, Threats) and PEST (Political, Economic, Social, Technology) analysis. Strategic thinking requires a holistic look at the environment and consider different aspects that may impact the product’s potential.

4Cs Marketing Mix Suppose you wanted to create a marketing model that is strong enough to “pull” customers towards your product, instead of “pushing” them to consume it. In 1990, Robert F Lauterborn defined a model that examined the environment for market opportunities known as “the 4Cs”:

1. Company: Examining the company’s internal resources, skills, vision and strategy.

Understanding how different opportunities could fall within the organisation’s vision, or whether it could steer or change it. A PO periodically scans the market for opportunities that would make sense for the company they are operating in to benefit from. He/she may identify gaps in the market that the firm can take advantage of due to: a. Previous product lines b. Existing stakeholder relations c. Cost cutting strategies This is often how new verticals are born and how a business evolves over time. 2. Context: the environmental context, regulations, technology, economic, social trends. It's important to identify whether market opportunities are temporary trends that quickly fade away once the next trend is in fashion. With today’s online trending ‘buzz campaigns’, it's easy to identify fads that come and go, and sometimes only last a few weeks. These kinds of opportunities may be beneficial in the short run, if the organisation responds fast enough to the appearance of a trend, but should be aware that the lifecycle of the product could be relatively short lived.

Similarly, the economic and legal playground could directly impact a company’s operations. New economic trade agreements with neighbouring countries could mean that an opportunity for cheaper suppliers with low import costs could give the company a competitive cost advantage. The needs, wants, behaviour, 3. Customers: psychology, profiles and identities of current and potential customers. Some customers prefer products that bring practical value over design, while others prefer design over practicality. The customers that use the product will give a good indication of what to focus on because they will vocalise what they need the most. A good PO will inform their stakeholders about any risks or limits that may exist in the organisation. Sometimes, customer needs might not reflect what's in the product roadmap and may also not be achievable or cost-effective. It’s up to the PO to decide if changing the product vision is possible or worthwhile. the relative strengths and 4. Competitors: weaknesses of competitors and trends in the competitive environment. Entering a fierce, competitive environment means that consumer demand is delicate and unpredictable. On the other hand, through innovation (and a high A2I -

Ability to Innovate), a product’s value may shine amongst its competitors - but what happens if the product can be easily emulated by the competition? That’s where the A2I comes in. Adopting a proactive strategy so that a product is always ‘one step ahead’ of the competition, keeping it in a solid market position. Marketeers refer to these elements as the 4 Cs (previously known as the 4 Ps)

Product Life Cycle Framework Each product (whether short, or long lived) goes through different phases over its lifetime. The Product life cycle defines five phases: Introduction, Growth, Shakeout, Maturity and Decline - each one having distinct attributes. Marketeers and strategists use this information to tweak their product strategy so that it best complements its current and future phases.

1.

Introduction - Characterised by low sales, supply and demand. Typically, this occurs before the adequate level of product awareness has been established. Serves as a good opportunity to test the market with different promotional activities. 2. Growth - Product demand increases, along with awareness and sales, towards the peak. As the peak is reached, sales stabilise and the rate of growth declines. The growth stage is a great time to grab the attention of potential customers and close the market gap.

3. Shakeout - The growth rate continues to decrease as more competitors enter the market as the product loses its ‘novel’ appeal. 4. Maturity - Sales are more steady and the main customers are made up of more loyal customers and less “early adopters”. The product has already tested the market and customers are more aware of the value that it offers. Focusing on keeping customers pleased and retaining them is key to extending this phase. 5. Decline or Extension- The last phase where sales decline. The product has been superseded, driven out of the market by the competition, costs to retain the product outweigh revenues, or the product has simply become outdated. Some products never really stop selling, and instead their decline phase is extended. Retrospective analysis during this stage can be used to enter the market with a new product, whereas in some cases, some products can be revived through innovative rebranding or features.

BCG Growth Share Matrix 1970s Strategic Management promoted the use of portfolio models to help businesses with classifying their product’s competitive strength. One of these tools which is still used today, is known as the BCG growth share matrix - which

gives insights into which investment opportunities are likely to generate cash through classification based on Market Growth Rate vs Relative Market Share. These classifications support marketing decisions in terms of pricing or releasing new products/product features based on their competitive reality.

The Dog - Represents a low market share in a stable market, that is not currently making profit. They have very little potential to be profitable in the future since the costs of increasing its market share

are likely to outweigh the potential gains. Dogs need increased marketing expenditure or price reductions to divert customers away from other products. Divesting products that are Dogs will release scarce resources which could be put to more profitable use. The Star - Fast-growing products that are clear market “winners”. The objective is to maintain market share until market growth ceases. The product incurs relatively high marketing costs because of the competition for new customers as market size increases. Typically, a Star will turn into a Cash Cow once the product matures in the market. The Cash Cow - A mature product that has already dominated the market (could have already been a Star) and is reaping the benefits (revenue) from previous promotional campaigns. Cash Cows can quickly turn into Question Marks. If “milking the cow” through additional product features/benefits is feasible, the Cash Cow can turn into a Star after becoming a Question Mark, however, if it is left to decline and lose market share, it will turn into a Dog instead. The Question Mark - Products that cannot yet be identified as one of the other classifications, may either become a dog or a star depending whether market share can be increased before the growth in the market stops. The potential for Question Marks is subject to experimentation and successful promotion.

Diffusion of Innovation A classic theory that is used in marketing and entrepreneurship, this perspective can help with predicting the market potential of a new product. It helps develop an understanding of how fast an innovative product can be adopted by the target market. The theory includes groups of potential customers that are more likely to adopt and buy the product in specific time periods. The rate of adoption depends on the attitudes and behaviours of consumers, as well as the product. However, when plotting a curve of the percentage of individuals that respond to the product over time, the curve tends to take the same shape regardless of the product. Each product tends to go through the five stages of adoption over some period of time. The speed of adoption depends on: 1. 2. 3. 4. 5.

The risk (cost of product failure or dissatisfaction); The relative advantage over other products; The relative simplicity of the new product; Its compatibility with previously adopted ideas, and behaviour; The extent to which its trial can be accomplished on a small-scale basis

6. The ease with which the central idea of the new product can be communicated7

Naturally, some consumers are more eager to experiment with new products or services before anyone else. Innovators include only 2.5% of the potential market. They enjoy trying out new things Everett M. Rogers, Diffusion of Innovations (New York: Free Press, 1983) 7

and sharing their experiences. Other consumers will wait for the Innovators to take the first bite into the product, and see what they have to say about it. The Early Adopter group will then tend to begin consuming the product. Early adopters are typically part of community groups or product “influencers” and make up 13.5% of the potential market. The product is then adopted by the Early Majority group, who are less likely to take risks than the preceding groups, and will not purchase the product before ensuring that it is successful first. The Late Majority group represents 34% of potential consumers. They could be less eager about purchasing the product, but do so anyway because of economic or financial reasons. Laggards (about 16%) are the last group of consumers that purchase the product, normally, this is around the time period where the product would already have a successor, they are comfortable with what they already have, and are less likely to respond to changes. This group is the hardest to onboard.

Chapter 8 Product Roadmap The Product Vision is broken down into goals over time, showing the future intent of the product, in order to achieve its vision. It enables value steering (improving value over time) and provides a clear direction to align stakeholders on the product’s future strategic decisions. Essentially, a Product Roadmap is a high level plan that can change over time. There are different types of product roadmap models and Scrum does not give any recommendation around which model to use choose the best fit for the product’s stakeholders. Two models worth mentioning are the GO Product Roadmap and the Now-Next-Later Product Roadmap. Both convey similar messages, however the level of detail differs between them. The purpose of the Product Roadmap is to provide a high level plan and direction of the product offering at a glance.

GO (goal-oriented) Product Roadmap 8

GO Roadmap A Goal-Oriented roadmap includes the following for each goal: ● A timeframe (e.g. Quarter) ● Key Feature/s ● Metrics to measure progress towards that goal

"GO Product Roadmap | Roman Pichler." https://www.romanpichler.com/tools/the-go-product-road map/. Accessed 9 Sep. 2020. 8

Now-Next-Later Product Roadmap9 Now-Next-Later Product Roadmap ● Easy to understand ● Splits goals that will be pursued either “now” “next” or “later”

"#now, #next, #later: Roadmaps without the Drudgery | by ...." 6 Nov. 2014, https://medium.com/@noah_weiss/now-next-later-roadm aps-without-the-drudgery-1cfe65656645. Accessed 9 Sep. 2020. 9

Product Value Product value is based on the customer perceived value that is developed through the benefits the product satisfies. Value can be affected by its nearest competing substitute, price, marketing strategy, delivery, user experience and brand. Similarly, value also influences product price, since price should be set in a region between the product’s costs and its perceived value. Product value isn’t just determined by revenue or profitability. There’s more than meets the eye when it comes to investing resources to create a product and continuously deliver value. POs often have a predicament on which features to prioritise first especially when stakeholders insist that they are all equally “urgent”. Some kind of measure needs to exist to be able to order features in the product backlog, and indicate their respective priority to the Scrum Team and the stakeholders. There are different approaches to quantifying priorities, and you may have heard of POs using “value points”, KPIs and ROI as quantitative measures. Certainly, numerous indicators can contribute towards measuring product value - as long as they remain relevant. The absolute best measure of product

value is and will always be based on user and market feedback.

Value Metrics & Evidence Based Management (EBM) Product Owners are responsible for the decision making of their product. They need to be able to determine the best outcome from underlying data, assumptions and prediction. Metrics are a supporting backbone to the science of decision making in most large organisations. Many business questions are posed in the day to day operations of an organisation - and outcomes are taken based on a combination of things including individual experiences and gut feelings. Data-powered decisions are the most objective and systematic method of supporting choices and are therefore a handy tool for determining product value, without being too distracted by emotions, ego or "gut feeling". Whilst in no means should a PO solely base their decisions on data, they are expected to conduct research, quantify value, measure customer feedback, inspect trends and use metrics to improve and grow their product.

Value Metrics Total Cost of Ownership (TCO): This defines the bigger picture of the total cost of the product value. From inception, to its complete life - it includes its past, present and future value. Net Promoter Score (NPS) - Based on asking customers: How likely is it that you would recommend our company/product/service to a friend or colleague? The replies are rated between 0 to 10 (10 meaning I would definitely recommend, and 0 meaning I will never recommend) . Customer feedback is calculated by identifying the difference between “promoters” (i.e. respondents that replied with a score of 9-10) and “detractors” (i.e. respondents who gave a score from 0-6) as a percentage. Promoters are the top customers that are loyal to the product, whilst detractors are customers that create traction to growth and are likely to damage the product’s reputation. The range of the score varies from between -100% to 100%, the higher the score, the higher the customer’s perception of the product’s value.

Leading vs Lagging Indicators Leading indicator: More future-oriented measures that can be used to enable change. Typically measured on a frequent basis. Lagging indicators: Measures output and tends to look at historical data to derive the result. Typically measured every month, quarter or year.

Evidence Based Management Evidence Based Management (EBM) is a movement that is part of evidence-based practices that are used in many different fields. Within the remit of business agility, EBM drives organisational initiatives through the best evidence available. EBM in Scrum - EBM is often mentioned within Scrum communities since it: (a) supports the pillars of empiricism through continuous improvement and adaptation (b) gives a transparent view of the value being delivered

Take a moment to analyse the following situation. A CEO is speaking with a product stakeholder, suggesting that a certain feature takes priority based on gut feeling.

Note that the stakeholder does not question the CEO for empirical evidence to support this suggestion.

Thoughts and Predicaments The CEO suggested shifting our focus toward a particular feature of the

product - but Sales have barely been affected. What value did this feature really bring? What data was used to support the CEO's decision? If the Team's velocity has only been going higher in the previous sprints then why are we losing market share?

Think a little about these questions and ask yourself whether you can think of any similar situations that you have come across in your organisation.

Digging Deeper

If an organisation measures velocity and market share, without measuring the delivered product value, then the complete flow of production has a missing link. ●

Are the features being developed actually useful to the user? Or were they given a wrong priority?

●

Do more features really equate to more product value?

●

Is the team being pressured to deliver faster and more features at the cost of quality, thus resulting in competitors taking market share?

●

Is product value delivered suffering at the cost of boosting velocity?

Here's where product value metrics come in Having these metrics in place can help answer these questions and thus influence future decisions. Each Sprint’s investment can be inspected against the value (financial or otherwise) that is output through the increment and thus decide on what to do next to maximise value. Developing more features may not necessarily bring more value. In fact, adding features that are not really useful to the users, may just increase technical debt in the long run. In this case, the features could even be reducing the overall product value. The best measure of impact is based on Product Value measures such as

customer satisfaction and frequent releases, not the number of features in a release.

A note about velocity ● Velocity is measured through a subjective measure, and is personalised for every team ● Velocity is not a measure of product value. The amount of work a team does is separate from the value that is experienced by a user. A team may be delivering many features, at a high velocity, that mean little to nothing to the customer. In this case, velocity is high, whilst product value remains low.

Chapter 9 The EBM Guide The EBM Guide10 defines four Key Value Areas (KVAs), each having their own Key Value Metrics (KVMs). KVMs measure both internal (measures related to employees, product development and release data, education, product defects, internal costing) and external (customer usage and satisfaction, market data) factors.

KVA 1 - Time to Market (T2M) Purpose: Expresses the organisation’s ability to quickly deliver new capabilities, services, or products KVMs include: ● Release Frequency ● Cycle Time ● Lead Time ● Time to Repair ● Release Stabilisation Period ● Release Frequency 10

Evidence - Based Management

https://scrumorg-website-prod.s3.amazonaws.com/dr upal/2019-05/EBM_Guide%20January_2019.pdf Accessed 3 Sep. 2020

● ●

Build and integration frequency Time to learn

Measured in: Time, duration Used to: Identify and remove bottlenecks, introduce automation, improve operational processes, reduce delays and increase customer engagement through fast response. Also, increases product competitiveness, sales and gains competitive advantage

KVM 2 - Current Value (CV) Purpose: Reveals the value that the product delivers to customers, today KVMs include: ● Revenue per Employee ● Product Cost Ratio ● Employee Satisfaction ● Customer Satisfaction ● Customer Usage Index - A measurement of usage, by feature. It can show whether customer usage meets expectations. ● Investor Satisfaction Measured in: Various units of measurement, depending on the method used. Derived from

marketing metrics and can range from financial metrics, surveys, social media feedback to qualitative customer feedback or focus groups Used to: Analyse internal and external factors that impact customer and employee attitude and happiness. Decide which product features should be retained or dropped.

KVM 3 - Unrealised Value (UV) Purpose: Suggests the potential future value that could be realised if the organisation could perfectly meet the needs of all potential customers KVMs include: ● Market Share ● Customer or user satisfaction gap : The difference between the customer’s desired and current product experience. Measured depending marketing metrics to groups

in: Various units of measurement, on the method used. Derived from metrics and can range from financial qualitative customer feedback or focus

Used to: Predict potential value and future benefits. Can be important to assess new products or feature

value. Typically, mature and declining markets will hold more CV than UV, whilst new and growth markets will hold more UV than CV. In the following graphs, Product A is in the ‘Growth’ phase of the Product Life Cycle, whilst Product B is in the ‘Decline’ phase. Product A’s UV is greater than its CV, whilst Product B’s CV is greater than its UV.

Many investment choices can be driven by a high UV. When CV is high and the UV is low, investments may be redirected to other areas or products that have more future potential for return, or otherwise, a greater UV. The favourable investment choice is Product A over Product B, since Product A has more future potential of value.

Since POs are expected to be Experimenters, calculating the UV can help support a business case for one investment over another. Similarly, comparing UV with CV, helps identify gaps of value to investigate sales trends.

KVM 4 - Ability to Innovate (A2I) Purpose: Expresses the ability of a product development organisation to deliver new capabilities that might better meet customer needs KVMs include: ● Feature Usage Index ● Innovation Rate ● Defect trends ● On-Product Index - measures the amount of time a team spends working on the product, the efficiency of how a team is run and their relationship to the product’s growth ● Installed Version Index ● Technical Debt ● Production Incident Trends ● Active code branches, time spent merging code between branches ● Time spent context-switching - Context switching reduces focus and can delay the delivery of value in terms of A2I and T2M also.

Measured in: Frequencies, occurrences or other metrics that impact innovation and technical debt Used to: ● Analyse internal and external factors that impact customer and employee attitude and happiness. ● Increase product competitiveness, sales and gain competitive advantage ● Determine how quickly the organisation can pivot their product offering The A2I can also be improved in other ways, such as setting ‘no meeting’ days to increase focus, increasing the cross-functionality of the team members and team co location. Using these KVAs and KVMs will help a PO: 1. Obtain an evidence based measure of Value 2. Identify areas to improve 3. Increase value through improved decision making 4. Adapt, Monitor and continually improve

Product Ownership Myths

“Product strategies often fall through and are therefore not needed”

FALSE: Product Strategies determine the viability of a product by analysing the unrealised customer value in the market, understanding whether it is possible to obtain market share through the product, how to focus and deliver customer value and remain competitive. A weak product strategy does fall through, a strategy that is not kept up to date also falls through. Failing to reflect changes into the strategy, means that pivotal points that determine the product success are not sufficiently thought over or communicated, thus, this is what can actually make the product fall through.

“Product Owners deal with internal operations, Product Managers deal with product strategies”

FALSE: Product Managers are not part of Scrum. The Product Owner is responsible for both, is expected to

refine the product backlog and answer the Developers’ questions internally. These tasks can be delegated to the Developers, but the PO is still held accountable. The PO is also responsible for communicating with stakeholders to set the product vision, strategy and roadmap. Product Management and Product Ownership do overlap.

“A Product Owner must dictate a clear Sprint Goal”

FALSE: The Sprint Goal is collectively communicated and formed by the entire Scrum Team. The PO can help make it clearer by explaining how it aligns with the Product Vision.

Part 3 Tactical Product Ownership ❖ Read this section to understand the responsibilities of the PO and how they tie into the internal business flow, Scrum principles and how a PO can react in practical scenarios

Chapter 10 Validation, Interaction and Feedback Loops Validation, Interaction and Feedback Loops are an opportunity to: ● Learn, Inspect and Adapt about: ○ The market needs ○ The client and stakeholder needs ○ Improve the prioritisation in the Product Backlog ○ The product In the worst-case scenario, if the product fails, it will fail early and inexpensively -reducing sunk costs. Feedback Loops in Scrum: ● The Sprint is a time-boxed container full of feedback loops (events) that give an opportunity to learn ● Interaction with the Scrum Team and stakeholders ● Artifacts which include validations and criteria that give information about the expectations of the product’s features and state

Learning checkpoints (Validation) ● Daily Stand Up ● Planning ● Review ● Retrospective ● Refinement

Empiricism and Product Ownership ●

POs regularly inspect work done (including their own) by demonstrating increments during Sprint Reviews and testing releases in the market. Inspection leads to adaptation when market feedback is received. Apart from this, constant communication with stakeholders and the Scrum Team allows for opportunities to discuss the product,its requirements and improvements that can then be reflected in the Scrum artifacts (e.g. Product Backlog Refinement).

●

Growth can only stem from learning from change and adapting towards improvement. Product Backlog Refinement is one of the main points of product adaptation, as well as updating and improving the product vision, roadmap and strategy. When product priorities shift, key performance indicators (KPIs) for value may reveal that customers prefer certain features over others, which means that the perception of value can differ from one release to another.

●

Be transparent! All aspects of a good Scrum Team depend on transparency at all levels. Open communication between members of the Scrum Team, key stakeholders and the clients are what

drive empiricism. Without transparency, there can be no improvement. The PO can ensure transparency by keeping the Product Backlog updated and refined, communicating the vision and the product strategy regularly, and ensuring continuous communication with the clients, stakeholders and Scrum Team. Remember that Openness (speaking openly), Courage (speaking about things that might be difficult to talk about) and Respect (trusting what others speak about) are core values in a Scrum environment.

The Product Owner Scrum Event Matrix

Scrum Event

Who attends?

PO’s Involvement

Daily Scrum

The Developers are required, while the rest of the Scrum Team is optional

Minimal

Sprint Planning

The Scrum Team

Required for the first half

Sprint Review

The Scrum Team and any key stakeholders such as clients, focus groups, external testers

Required (High involvement)

Sprint Retrospective

The Scrum Team

Required (The PO participates as a peer team member in the meeting)

1.

PO and the Daily Scrum Meeting ● POs attending a Daily Scrum meeting is optional, however participation is normally meant for the Developers, not for the PO or Scrum Master. Therefore, it is not considered the

best place for the PO to answer product questions or to interrupt them. If members of the Team have any product related questions, it is best to address them after the Daily Scrum. 2. PO and the Sprint Planning ● Sprint Planning serves to plan the work to be performed in the Sprint. This plan is created by the collaborative work of the entire Scrum Team. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. What can be achieved in this time-box may be influenced by additional practices that are however not prescribed by Scrum. ● Since the Sprint Planning meeting is divided into two parts (described in more detail in Part 1), the Product Owner is not needed in the second half of the meeting.

3. PO and the Sprint Review ● The PO’s responsibilities in this event include demonstrating the done features, inspecting them, balancing user expectations, planning the product’s future and discussing stakeholder feedback. ●

The Sprint Review exposes the work done to the stakeholders and helps to determine whether it meets their expectations. The PO should be able to balance stakeholder

expectations with the product’s development possibilities. ●

The Sprint Review is a good opportunity for collecting user feedback - although it should not be the only time or place to do it. Feedback needs to be ongoing and can be asked for at any point during the Sprint.

4. PO and the Retrospective ● The Retrospective is meant for the Scrum Team’s inspection and adaptation. The PO is included as a Scrum Team member who is meant to attend and contribute to this event. ● The outcome of the Retrospective includes actions for continuous improvement that are added as part of the next Sprint backlog.

Product Owner Relationships Product Owner and Scrum Master ● The Scrum Master helps the Scrum Team understand Scrum theory, practices, rules, and values. They can help support the Product Owner with the best practices of the Product Owner role, such as defining the Product Goal, managing the Product Backlog and helping the Developers understand Product Backlog Items. The Scrum Master can also assist the Developers by helping them learn techniques that improve their effort estimations and causing the removal of blockers that they might encounter. ●

During Scrum events, the Scrum Master can be very supportive towards the Product Owner through the facilitation of events - allowing everyone to contribute, while keeping events within their timebox.

Product Owner and Developers ● The Developers are responsible for developing the backlog items and producing them in a done state. They are responsible for bringing a usable increment to life. A PO will normally be responsible for one product, having one product backlog. There may be multiple Developers

working on this product backlog, each having their own sprint backlog. Developers are more likely to produce quality when they are working in a single Scrum Team rather than being distributed amongst different teams. POs can support the Developers in the best way by being there to answer product related questions, aligning them with the Product Vision and strategy and managing the Product Backlog.

Product Owner and Clients/Stakeholders

●

Ensuring that the Product Backlog is kept clear and is understandable by people outside of the Scrum Team. The PO will often communicate the product roadmap and strategy with clients and stakeholders. They will often ask for updates regarding the product - Sprint Reviews are the perfect opportunity to discuss and demonstrate the product’s development. Feedback is obtained from these parties and contributes towards the product value generation.

Product Owner and Upper Management ● A crucial part of the PO’s interaction with Upper Management is to ensure that the product vision and strategy are aligned with the business vision. Healthy dialogue on how the product fits into the organisation’s objectives will help align the organisation on different levels. Beyond this, the Product Owner should be empowered to independently take decisions on the product without intervention from upper management.

Acceptance Criteria and Definition of Done Acceptance Criteria Each item on the Product Backlog has a description, a priority, an estimation and value. Along with this, items need to have one or more acceptance criteria such as functional/non functional requirements, UX requirements and so on. This helps the Developers understand how the requirements can be satisfied and how the feature can be tested.

Example:

Note that the syntax used in this example’s Acceptance Criteria is called Gherkin11 (Given, When, Then). This is one of the many practices that organisations can utilise to help standardise their acceptance criteria. Definition of Done

"Gherkin Syntax - Cucumber Documentation." https://cucumber.io/docs/gherkin/. Accessed 4 Aug. 2020. 11

At the end of every Sprint, the increment needs to be “done”, i.e. all acceptance criteria for each Product Backlog Item are met plus, the increment meets the organisation's Definition of Done. The Developers always have the final say of whether the increment is ‘done’. The Definition of Done is created by the development organisation (or Developers if none is available from the development organisation). The Definition of Done is a quality standard that needs to be understood by everyone and is not normally limited to a single Scrum Team. A shared, transparent and mutually understood Definition of Done is needed across all teams working on the product. Any individual that is developing the product, should be able to understand whether the level of quality that they are producing complies with the Definition of Done, to ensure that the work is suitable enough to be included in a usable increment. Examples: ● All increments comply with legal, organisational and compliance standards ● All increments are clearly documented ● All increments are tested through an automation pipeline

The Definition of Done can always be improved and refined. The Retrospective is a good time to suggest improvements.

Chapter 11 Requirements Requirements are a main responsibility of the PO, who is the key contact point for clients. Before requirements are broken down into Product Backlog items or features, they need to be validated for completeness, scope and clarity. Requirements stem from different sources including workshops, discussions (informal and formal), Sprint Reviews, market analysis, legal constraints, changing technologies and more. The Product Vision, Strategy and Roadmap are often used as a starting point and guidance for the development of requirements for the first iterations (normally used to develop the Minimum Viable Product).

During requirements gathering, the PO needs to understand some potential challenges:12 ● Problems of Scope - Requirements need to be managed in a way that they are kept within the product and business scope, or, where necessary, and only if valid, the PO changes scope and reflects that in the Product Roadmap and Vision. ● Problems of Understanding - Requirements may be only partially communicated, since clients may not be completely sure of what solution they need, or their problem domain. They may even leave key information out. Asking key questions, following questionnaire formats and also educating the clients about the environment and product help reduce this problem. Incomplete requirements are those that cannot eventually be tested (in that the acceptance criteria is vague or non-existent) and do not clearly indicate what problem or need they have to address. ● Problems of Volatility - Some requirements are more volatile than others. Temporary requirements call for more attention because they may only deliver business value in the short

"Issues in Requirements Elicitation - SEI Digital Library." https://resources.sei.cmu.edu/library/asset-view.cfm?asseti d=12553. Accessed 25 Aug. 2020. 12

term. Changing requirements may also invalidate or impact other related requirements. In the end, requirements are sized down to be more manageable. As a guideline, each item in the Product Backlog: ●

●

●

●

● ●

Is clearly understood by any Scrum Team member - Including keeping it simple and straightforward, without using complex jargon. Standardisation can be used to keep formats consistent. Can be tested against an acceptance criteria A clear acceptance criteria is shown for every item, so that quality is set as a precedent. Can be completed in one Sprint - If the Developers see that the item is too large, then breaking it down into two or more stories will help make the work more manageable. Is prioritised based on business value - Its good to include the business value that each item is meant to deliver in the user story itself. Some organisations use Value Points, which is a good indicator of value. A brief description of the value helps to engage and align the Scrum Team. Clearly shows dependencies with existing Product Backlog Items Clearly points out risks related to the requirement

Has enough information so that it can be given an estimation of effort. Sometimes, the necessary detail is not readily available, and may require prior research or experimentation. In that case, a different task or item can be created with the goal of obtaining this knowledge, before estimating the main task. Should be aligned with product and organisational vision and strategy Needs to be kept current so updates are continually done as priorities, dependencies, business value, scope and requirements change

●

● ●

During the product life cycle, the backlog is continually refined, as more knowledge is gained about the product. Pichler13 advises that a healthy product backlog needs to continually have the four key attributes described in "DEEP". DEEP stands for: 1.

Detailed Appropriately - Top priority items will have enough detail to be well understood, so that development can start on these items.

2. Estimated - Each item will need to have an estimate in order to help plan the release. "Make Your Product Backlog DEEP - Roman Pichler." 8 Feb. 2010, https://www.romanpichler.com/blog/make-the-product-ba cklog-deep/. Accessed 14 Sep. 2020. 13

Lower priority items can have less precise estimates - these will be updated as more knowledge is learned about the product. 3. Emergent - Items may have their priority, description and estimates changed. They may even become irrelevant to the product and be removed as more is learnt about the product requirements. 4. Prioritised - After releasing increments to the market, users will communicate their feedback on the business value of the product. New priorities will emerge as increments are inspected and more is learnt about the product.

Nonfunctional requirements Some requirements are not directly related to the product, but still to be there. Non functional requirements (or constraints) can be related to compliance, UX, performance, transparency, privacy and so on. They are part of a set of standards that the product needs to meet, and are non functional. Examples include:

Non functional requirements examples: Product X needs to: ● Be user friendly and easy to navigate through ● Comply with industry standards ● Perform efficiently, even on low-end devices

These kinds of requirements can be included in the organisation’s Definition of Done. When it comes down to specific tasks that are needed to carry out work directly related to non functional requirements (e.g. implementing a data policy for user privacy, carrying out UX research to determine interface layout), can be included as separate product backlog items.

A little about User Stories Although Scrum does not require the use of User Stories, they are one of the most used and

recommended methods by Agile professionals to communicate requirements. The main purpose of User Stories are to simply keep things concise and to the point. Requirement details are encouraged to be communicated face to face, so that unnecessary lengthy requirements documents are avoided. The story needs to always communicate three key things: 1. The role - Who benefits from this requirement 2. The behaviour - The action that can satisfy the need 3. The value - The reason the requirement is there, and the benefit it brings Also, stories should have: ● Business value description - How the business value impacts the product or organisation ● Acceptance criteria - What criteria needs to be met to consider the work to be accepted

A common formula for User Story components is known as “The Three C’s”

The 3 C’s of User Stories ● CARD - User stories are meant to fit in a ‘card’, which means that they’re meant to be kept concise and short ● CONVERSATION - Details do not need to be exhaustive. Communication around User Stories is encouraged.

● CONFIRMATION - Acceptance Criteria is available to confirm that the user story delivery is successful

Although Product Backlog Items can be portrayed using User Stories, other formats can also be used. Diagrams, models, presentation files, videos, spreadsheets or other information that effectively communicates the customer’s need, can and should be used if it helps deliver and communicate the requirement in a better way.

Product Backlog Management The PB is a living artifact filled with product backlog items (PBIs) having requirements that evolve as long as the product exists. One product necessitates its very own PB and is always kept visible to the Scrum Team and stakeholders. When a product initiative starts out, the details about how long it will take, how much it will cost and how complex it will be, are more unknown than known. However, as time passes by, and more feedback loops are done, the Scrum Team gets a better idea of : ● ● ● ●

●

What is required to deliver the product features Potential issues become clearer, therefore risks and effort estimates become more accurate Technical blockers or dependencies that were not apparent at the start The quality criteria that often develops as stakeholders test out prototypes during Sprint Reviews The changes in requirements that manifest and affect the sprint goal.

Therefore, certainty increases as more and more information about the product and resources are gathered. A concept that describes this theory is called the Cone of Uncertainty, which can be used in complex environments to predict the likelihood of work to be done over a number of sprints. This theory can be especially observed when Team estimates become more accurate, the more Sprints they complete (note, that estimates are never perfectly accurate, and therefore there is always at least some uncertainty).

How does this affect the Product Backlog? The PB is a fluid artifact, it is never complete nor exhaustive. When there are changes in the market, the PO is responsible for changing the PB to reflect the impact of the change on the product’s development. The Developers may have questions regarding the information of the PB items, and the PO is expected

to collaborate with them in order to ensure that the PB items are well understood. This process is called Product Backlog Refinement. The time spent on refinement is as much as the Scrum Team thinks is necessary to create enough Product Backlog items that can be pulled in for the upcoming two or three Sprints. The more uncertainty there is, the more changes are likely to happen in the PB. Shifts in priorities, feature requirements are all reflected in the PB. When a Sprint Planning event takes place, the Developers determine which Product Backlog items they will work on and complete during the Sprint. In some cases, the Developers might not be able to completely forecast the items that will be done at the end of the Sprint. They can, however, start the Sprint with the items that they feel are most likely to be done, then continue to analyse and decompose the remaining PB items during the Sprint. As long as the PO makes sure that the Sprint Goal is clear, the Developers remain responsible for the Sprint Backlog and can decide to bring in more items from the Product Backlog during the Sprint.

What does “Product Backlog management” include?

PB management tasks include the following: ● Creating new PB items ● Ordering and reordering items in the PB based on their priority (or new priority) ● Estimating the effort of the items ● Reviewing and refining the items with stakeholders and updating their description and details reducing and eliminating ● Identifying, dependencies between PB items ● Breaking down larger items into smaller items that can be developed during the duration of a Sprint (Features/Epics, User stories/cases, tasks etc) The PO decides how best to order PB items based on his/her judgement, at any time he/she thinks is ideal. Their perception of the product’s value helps them assess which work needs to be done first to deliver the value that the users want. The measures of value are not constantly set in stone thus the PO decides which factors best determine product value, based on judgement and experience.

Chapter 12 Release management A release may be done at any time (not necessarily at the end of the Sprint) even if it is a small increment - as long as it delivers some kind of improvement or new outcome. The PO determines when to release a done increment and this does not necessarily have to be at the end of the Sprint. Releasing an increment to the market presents an opportunity to learn about the business assumptions built into the product. Through collaboration with the Scrum Team, it's possible to improve the release process through automation of testing and deployment (such as building continuous improvement/continuous deployment pipelines). It's also important for the PO to understand impediments that occur during the release process, how they impact the product delivery, and work with the Scrum Team to reduce and remove them.

Release Planning Planning the release is all about strategising and negotiating product delivery. However, the higher the project uncertainty, the higher the probability of having an inaccurate release date. Before concentrating on the method used for release forecasting, consider the following factors before planning a release: Development Uncertainty - As discussed before, in the Cone of Uncertainty, uncertainty greatly impacts the planning process. In earlier Sprints, tools, processes, technologies to be used and functionalities may still have gray areas. This means that dependencies, specialised skills, license/tooling costs, infrastructure and architecture decisions still need to be taken. The outcome of these decisions will influence the entire product timeline. Initially, focusing on a Minimum Viable Product as an early release will also test these key decisions. Estimation Errors - A release plan takes estimates into consideration, but it should also take estimation errors. Depending on the number of sprints the team has already run in the past, data for the estimate vs the actual amount of effort spent on a

feature, will give an indication of the error rate of estimations. The more data available (the more Sprints this specific Developers has finished together), the more reliable the error rate of estimations. Knowing that, if the error rate has typically been +/- 20% of estimations in previous Sprints, this buffer can also be applied to the release date. Some tools on the market provide best and worst case scenario predictions through Monte Carlo simulations, Throughput and Burndown charts. While these predictions are not meant to be accurate, they can be useful for discussions with the team and stakeholders. Integration - Functionalities sometimes need to undergo an integration process before being usable to the market. Examples include integrating with third party APIs or even integrating with a client’s platform. Integration is a common dependency to having a shippable product and can act as a bottleneck. Examine the following questions if integration is needed: ● Is all the integration data available to the Scrum Team? Are endpoints, test cases, data and so on available in early Sprints? ● Could changes to the third party platform cause significant changes (and delays) to the delivery of the increment? ● Is personnel availability required from the third party to integrate successfully?

To improve predictability, analyse the possibility of integrating the increment at the end of each Sprint. The best and ideal product increment is unified and includes the integrated work of each team working on the product. Therefore, Sprint Reviews will be used to inspect the integrated increment, not individual increments developed separately. Dependencies - Any dependencies that can influence the projects: ● Other departments that may need to give specialised input (e.g. to meet the Definition of Done) ● Tool delivery - Such as testing devices, or any tools required to carry out the work ● Leave/Vacation - both internally and externally (clients, third party suppliers etc) ● PEST changes - The increment may be influenced by environmental changes such as policies or laws (data/industry), economic demand, social changes (e.g. fads), technology (new frameworks being developed that may result in new demands) ● Changes in core Scrum team members (turnover or new hires) Code Freezes - Use judgement in scenarios where some time buffer might be needed between an increment’s last commit which has a high impact,

and the actual release date. Giving some extra time for pipeline runs as well as manual testing, can significantly improve the quality delivered, since commits done towards the end of the Sprint timeline may have unintended results or bugs that have not yet surfaced. On the other hand, buffers also extend your Time to Market. The quality of testing and quality checks depend on the state of your infrastructure and in an ideal scenario, code freeze buffers are not needed. Scope Changes - Do requirements change frequently? Have they changed often in the past? If so, then it is safe to assume that requirements will keep changing, depending on how much leeway for change the product vision allows. Bottlenecks ● Are there limitations in resources and skill expertise? ● Are key resources shared between other teams or projects? ● Is the team or specific individuals over their capacity limit? ● Are any of the above applicable to dependency teams/individuals or suppliers? ● Is the decision making process slowing down? Creating a visualisation of the process and flow can help identify areas where bottlenecks are

happening. A method known as Value Stream Mapping can be used to analyse the flow, identify areas of waste or slow-down. Fixed Constraints - The degree of flexibility of time cost and quality differs between projects. In some cases, constraints apply and cannot be changed: ● Quality - Some product releases are subject to quality checks which may be required depending on the industry. For instance F.D.A. approvals, PCI DSS compliance, iGaming/Gambling certification and so on. In other cases, it may simply require the approval of a major stakeholder that is involved with the product. Depending on the complexity, approvals not only eat up more time before release, but may result in back-and-forth communication and product rework. ●

Fixed deadline - Certain products depend on events, temporary fads or simply need to release at a certain date to remain competitive. For instance, changes to an eCommerce website that promote Christmas sales need to be planned proactively to avoid missing a pivotal deadline. Similarly, products may only be required temporarily for specific events such as festivals,

elections or workshops. In these cases, missing the deadline means that customer value drops to zero and that the product is no longer feasible to develop. In both cases, the implication on release planning is major. A reactive stance is not an option - so release planning is even more critical to the product’s success.

Forecasting Different methods of forecasting can be used for your release. Scrum does not specifically require any single forecasting method, however one of the most popular forecasting methods that the PO can use is known as the Release Burndown Chart. ●

Release Burndown ○ The release burndown chart illustrates the predicted remaining effort over the remaining number of Sprints. ○

It includes best case and worst case predictions and can also be plotted based on how the team’s velocity has fluctuated in the past.

○

The actual effort is also plotted on the chart at the end of every Sprint, so that the trends of the difference between the predicted and actual effort are made visible.

One caveat of the release burndown chart is that it only considers effort that is estimated within the product and sprint backlogs. In practice, there may be other buffers or dependencies that may push the release date. For instance, a company may have a release procedure that requires third party validation before releasing to the market. Alternatively, releasing the product may require integration or QA with a third party, which in turn, requires additional time before the product is available to the market.

As such, the general rule of thumb is to consider all potential factors that can impact a release date.

A note about Velocity: Measuring and tracking velocity is used to better understand the team’s predictability. However, velocity is not a direct output of product value, and therefore using velocity to predict a release date does not guarantee that the desired value will actually be ready for release. On the other hand, tracking the value that is included in the “done” increments, will give a better idea of when to expect the desired value to be ready for release.

Releases and Risk Management The advantage that Scrum delivers is that the PO is able to release often to also gather customer feedback more frequently through a short feedback loop. However, another advantage is that small, frequent releases help reduce the impact of a buggy release, and also help reduce the risk of production defects happening all at once, when releasing a large buggy release. Having (when possible) smaller releases, narrows down the impact to those few features included in the release, and may even prevent future similar incidents from happening with increments that are still in progress.

Releasing in smaller chunks In a scenario where a B2C software provider is working on releasing a loan module for their client, a major Bank, they may decide to split the release of a loan module by two sets of features. First, the PO plans a release for the features that cater for

personal loans, then they plan the following release for the features that serve commercial loans. The first Sprint for personal loans is over, and the PO sees that all the acceptance criteria has been met. The end users also seem happy with the features they tried during the Sprint Review. The PO decides to go ahead with the release. A few days after the personal loans release is live, a bank operator notices that the home loan down payment calculation is not being calculated correctly. When the operator raises this issue, the Scrum Team realises that there is a rounding calculation error that is in fact, affecting all downpayment calculations. They make sure to

inform the stakeholders about this, and commit to release a fix within the next 12 hours. The Scrum Team analyse the root cause, and realise that this issue could also be present in the commercial loan build that is currently being worked on. Through learning from customer feedback, the Scrum Team now has a better idea of what to look out for, and will verify that the rounding in the downpayment calculation is functional prior to releasing the commercial loan features. Apart from this, they will also add “rounding calculation checks” in their test cases prior to any loan module releases.

What was the outcome on product risk and impact?

By having two smaller releases of the loan module, the risk of incorrect down payment calculations was exposed prior to releasing the commercial loan features. The client had confirmed during one of the meetings, that commercial loans are given to prestigious clients, and that the largest part of the bank revenue comes from these types of loans. By releasing and learning from the “less critical” personal loan features, the Team was able to fix this issue prior to releasing the commercial loan features, thus avoiding rounding miscalculations on very large amounts, that would have not only impacted the product’s value, but also the organisation’s and Bank’s reputation.

Release Frequency 1. Releasing too rarely The core concept of Scrum is to work in iterations, giving more opportunities to learn, release, handle complexity and change. Missing those opportunities too often goes against the principles of Scrum. So here’s what you lose if you release too rarely: ● Competitive advantage - Your Time to Market is impacted, you react slower to changing consumer demands, so you give the competitors an upper hand ● Delay in customer review - Your customers won’t see what you’re developing for longer stretches of time. Delaying customer feedback delays your product improvements. ● You lose touch with the customer Communicating with customers without giving tangible releases for them to see and try will keep them ‘blind’ from what you’re building. If you rely on screenshots and write ups to communicate progress, they may easily imagine something completely different than what is actually being developed. ● The Developers will find it harder to fix defects Going back to change something that was developed 3+ Sprints ago will require additional time and might also impact items that were developed after that.

2. Releasing too often How do you know whether releases are being deployed too often? Do your end users have time to “digest” the new features? Or does the product change so often that they cannot get used to it? When large eCommerce websites such as eBay release a style change on their website, they make sure that there is ample time for users to digest small changes, so that a transition to a new style is not done suddenly, but over a period of time, where they can still use the website normally, without having to wonder where to navigate or click. Release frequency impacts user experience. When Apple releases a new iPhone version, users sometimes complain that they “just” bought the previous one, and that they would have waited for the latest version had they known that it would be released so soon. Thorough market analysis however, determines how to strike a balance between new releases and customer value. That is, that releases are frequent enough to provide increased value and innovation, without diminishing overall user experience.

Although, releasing often and early is actually the best way to test assumptions (especially when the PO is taking the experimenter stance), he/she should also consider the following: ● ●

●

Does the release meet the quality criteria in order to avoid bugs or issues? Do the releases contain significant changes that impact the user’s experience? Can they be broken down into smaller changes over longer periods of time? Will reduced release frequency mean that releases will have better quality and overall higher product value?

Releases require balance at the core, release the minimum releasable features, release at a good pace, ensure that the increment always meets the definition of done.

Chapter 13 A PO's Tricky Situations - What to do, and when to do it Having the theoretical elements of a Product Owner Role in place is just the baseline of what it takes to be a PO. The reality is that they face challenges and are often in the middle of attempting to balance the client’s expectations without over-promising. Here are some typical case scenarios that a PO will face, with suggestions on how to approach them. These cases have been taken from real life examples and are aligned with case scenarios that have been presented in previous Product Owner Certification Examinations.

Unplanned work & technical debt arises Keep in mind that this really is a problem for everyone! The customer, the Scrum Team, the product’s brand and the organisation’s reputation. Technical debt slows down releases, velocity and impacts product value, product quality. When it gets out of hand, the Developers would end up spending more time stabilising the system, and firefighting

issues which affects the team’s innovation rate and morale. Technical debt can be a result of pressure on increased velocity, but slows down velocity in the long run. In other words, putting pressure on performance may lead to increased velocity at the cost of releasing poor quality. In software development, this expense will appear as bugs which will then need to be fixed (urgently in most cases) and consequently, delay the development of new features. Take action to reduce or eliminate future technical debt. One approach is to dedicate 20% of each Sprint to improve the codebase to tackle existing debt. The Developers can also refine and improve the Definition of Done to minimise future technical debt. If it’s a problem for everyone, then everyone stands to gain. Find the root causes, invest the time required to propose better quality checks, more communication and take a proactive stance. Turn the investment needed to improve into a win-win situation.

The increment is delivered, but quality is an issue Best case scenario: someone in the Scrum Team points it out prior to release

Less ideal: Stakeholders points out quality issues during Sprint reviews or UAT Worst case: Stakeholders point this out after production release (and you didn't flag it) Key actions to take: 1. Understand whether the acceptance criteria and definition of done include the level of expected quality. Take steps to update them for the next Sprint if necessary 2. Ask the Scrum Team whether the definition of done and acceptance criteria are well understood 3. Discuss the root cause of the quality issues with the Scrum Team during the retrospective. Work with them to improve the following Sprints 4. To ensure transparency, discuss the quality issues and concerns with the stakeholders, including the actions that will be taken to mitigate them 5. Investigate whether the Sprint Reviews have been helpful enough for the stakeholders to inspect the product increment

Balancing time between client discussions, Product Backlog refinement, meetings and other duties is a challenge

POs inherently need to be able to work with people, build relationships and maintain them. This includes, being available for the Team if they have any PB related questions, and liaising with stakeholders to discuss product requirements and demonstrate available features. Without frequent interaction with key personnel, issues involving alignment, transparency and risk will emerge. Sprint reviews are a great opportunity to solidify these bonds, since both the Team and key users will be present. At scale, with multiple teams working on the same product, this can be challenging. Keeping a single Product Owner on the product is even more important, to reduce complexity within its network of people. Delegating tactical product tasks to the Developers helps with keeping the PO dedicated to the product’s users, stakeholders and teams.

Sprint backlog items haven't been completed at the end of the Sprint and there is no releasable increment: Best case scenario: someone in the Scrum Team points it out before the end of the Sprint Less ideal: you find out at the end of the Sprint

A possibility here is to ask the Team to re-estimate the effort that they think will be needed to finish the previous work, before starting new features. Thus the next Sprint is focused on finishing this work. During the retrospective, the Scrum Team could discuss why this happened, and suggest improvements for the following Sprints. The Scrum Master can also help the team to learn methods that can help them predict estimates better.

A delivery needs to be expedited to capture a market opportunity Best case scenario: Create an understanding of the delivery flow, understand dependencies and bottlenecks that create delays. Work with the Team to improve the stream of value. Worst case scenario: Introducing overtime or hiring more team members Overtime rarely results in increased value delivery. In some cases, it even backfires due to team member burnout and takes a hit on product quality. Hiring additional staff increases complexity. The value added from new staff is not something that is achieved within their first period of employment, but

only when they are sufficiently trained and acquainted with the Scrum Team and the product, its features and market. Bruce Tuckman14 describes the transition that new hires go through with the rest of the team, known as Forming, Storming, Norming, and Performing model. In the short-run, this can also cause delays if key team members are needed to dedicate time to training the new hires. Key actions to take: 1. Never postpone the start of a new Sprint 2. Examine the root cause of the situation 3. Replan the items for the following Sprint, negotiate new release date with the client, allow for some buffer if possible

Stakeholders requests a major change to a feature that is either in development or has recently been developed Key actions to take: 1. Always ask what triggered the change: ○ Is it an external factor that could not be predicted? "Developmental sequence in small groups. - APA PsycNet." https://psycnet.apa.org/record/1965-12187-001. Accessed 8 Jun. 2020. 14

Was this requirement communicated incorrectly in the past? 2. Changes are very likely to happen during complex projects and identifying improvement areas for the response to change can be done by measuring: ○ Cycle Time ○ Technical Debt ○ Velocity (for the same team) ○ On Product Index ○

The product is released, but there is little to no customer interest, due to a low Customer Usage Index. Key actions to take: 1. Interview users and customers, gather their opinions and feedback, understand what is causing the low interest 2. Create an evidence-based hypothesis that will reform the product in a way that meets customer demands. Experiment with this hypothesis to test the market response. 3. Adapt to the market needs with each release

Multiple Developers working on the same product are finishing their planned

features, but releases are delayed when increments are merged together. This could mean that: 1.

The definition of done is not incorporating integration, so integration testing is not being done during the Sprint 2. Communication and transparency between teams needs to be improved so that the software design includes integration specifications 3. Tasks related to integration are not being planned

Credits "Manifesto for Agile Software Development." https://agilemanifesto.org/. Accessed 10 Jun. 2020. "The Scrum Guide - Scrum.org." https://www.scrum.org/resources/scrum-guide. Accessed 9 Jun. 2020. Tuckman, Bruce W (1965). "Developmental sequence in small groups". Psychological Bulletin. 63 (6): 384–399. doi:10.1037/h0022100. PMID 14314073. Accessed 1 Apr. 2021. "Write the Product Vision - Martin Fowler." 5 Apr. 2017, https://martinfowler.com/articles/lean-inception/write-pro duct-vision.html. Accessed 2 Aug. 2020. "How Target Figured Out A Teen Girl Was Pregnant Before Her ...." 16 Feb. 2012, https://www.forbes.com/sites/kashmirhill/2012/02/16/howtarget-figured-out-a-teen-girl-was-pregnant-before-her-fat her-did/. Accessed 8 Jun. 2020. "Competitive Strategy, by Michael E. Porter. New York: Free ...." https://www.jstor.org/stable/258056. Accessed 1 Jun. 2020. Everett M. Rogers, Diffusion of Innovations (New York: Free Press, 1983)

"GO Product Roadmap | Roman Pichler." https://www.romanpichler.com/tools/the-go-product-road map/. Accessed 9 Sep. 2020. "#now, #next, #later: Roadmaps without the Drudgery | by ...." 6 Nov. 2014, https://medium.com/@noah_weiss/now-next-later-roadm aps-without-the-drudgery-1cfe65656645. Accessed 9 Sep. 2020. Evidence - Based Management https://scrumorg-website-prod.s3.amazonaws.com/drupal/ 2019-05/EBM_Guide%20January_2019.pdf Accessed 3 Sep. 2020 "Issues in Requirements Elicitation - SEI Digital Library." https://resources.sei.cmu.edu/library/asset-view.cfm?asseti d=12553. Accessed 25 Aug. 2020. "Make Your Product Backlog DEEP - Roman Pichler." 8 Feb. 2010, https://www.romanpichler.com/blog/make-the-product-ba cklog-deep/. Accessed 14 Sep. 2020. "Developmental sequence in small groups. - APA PsycNet." https://psycnet.apa.org/record/1965-12187-001. Accessed 8 Jun. 2020.

This book was done in collaboration with NBiG. Visit our website at https://nobullinitiativeguild.com/ if you would like to learn more about Product Ownership, Leadership, Scrum, or require personalised coaching or training.