Dans le cadre SCRUM que va faire le Product Owner, quel est sa responsabilité.

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

Clearly expressing Product Backlog items; Ordering the items in the Product Backlog to best achieve goals and missions; Optimizing the value of the work the Development Team performs; Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and, Ensuring the Development Team understands items in the Product Backlog to the level needed. The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.

De manière générale, il est seul à décider. Il peut demander conseils ou avis mais d'autres personnes ne peuvent pas prendre son rôle. Il ne soutraite pas.

Il est le seul à décider et est responsable du Backlog Product. Il ne doit pas sous traiter cette tâche avec d'autre PO. Il doit seulement se faire aider par aux.

When a product grows, it is quite possible that the PO will get help from other Product Managers and others in the organization who interact regarding the customer facing activities and knowledge of the product marketplace. While it is fine for the PO to be aided by the aforementioned people, it is NOT acceptable for the PO to attempt to proxy or outsource their PO Scrum Team duties, especially the Scrum Team facing duties.

• Product Value Maximizer
• Product Visionary
• Product Marketplace Expert
• Product Release Decision Maker
• Lead Facilitator of Key Stakeholder Involvement
• Other Product Owner role Considerations

• Setting up a product vision;
• Creating a product road map;
• Making a storyboard;
• Creating personas for the product;
• Defining assumptions that can be validated (i.e. using an MVP by the Development Team);
• Defining acceptance criteria or satisfaction criteria;
• Organizing a user story writing workshop (with customers and stakeholders!);
• Talking to customers and stakeholders about their use of the product;
• Doing market research;
• Setting out goals to achieve.

• estimate
• finding solution how to meet the sprint goal
• do experiment
• set up measurment

Make sure every body understand the challenge of refinement

• Facilitate Product Backlog Refinement workshops;
• Facilitate estimation workshops on value and effort;
• Teach the importance of shared responsibility in Product Backlog Refinement;
• Teach on metrics that can help the Development Team raise their transparency on the way they deliver and collaborate, i.e. lead time, cycle time, flow, time to learn, time to market etc.;
• Teach and coach the Product Owner and Development Team on self-organizing (anti) patterns, like the example given earlier;
• Help the Development Team in slicing PBI's in various ways, while still being able to deliver a “Done”-increment within the Sprint.

Value, as defined in a Scrum context, is the financial benefit an organization receives or might receive by creating and releasing the product under development or is a “societal benefit” instead of a financial benefit.

La notion de valeur est importante pour le product owner car cette valeur lui permet de donner de priorités. Plus un élément aura de valeur plus il sera prioritaire. La valeur sera donné par plusieurs éléments liés à l'usage et à l'utilité.

4 Steps to Optimize Product Value

1. Foster a Product Mindset A product mindset is about focusing on creating valuable outcomes. Output doesn’t matter if you are building things people don’t want or won’t use. Scrum is about delivering higher value more frequently.
2. Paint the Bigger Picture : product vision. What defining value is included in the vision. Example : conversion rate - revenue par custormer - user growth (new customer) use of feature…
3. Enable value emergence : The definition of value will be better and better sprint after sprint. Break things down smaller - create an understanding of value alignement - zoom in zomm out
4. Validate actual value : value is just assumption until validation

The definition of value comes by empirism.

aligning Product Vision with Product Value

En anglais la vision est le but à atteindre pour le produit c'est un peu l'équivalent du sprint goal pour la produit. Il répond à la question POURQUOI (WHY). Pourquoi avoir ce produit.

The vision describe the purpose of a product, why the product is created and what aims to achive for customers and users. What problems it tries to resolve.

It helps in motivating and inspiring people. It provides a common understanding of the direction.It helps the product owner to makes choise what to build and what not build.

1. Become the owner of the Product vision : be passionate about the product. You have to share it
2. share your vision often : it helps the dev team and the stakeholders what would be valuable.
3. Don't believe your idea is the best. Do not forget the product is for someone else not for you. Your ideas should be validated with stakeholder
4. Develop your vision iteratively. The vision is growing with others
5. Adapt your vision as you are learning Do not be afraid to change it as you are learning adopt feedback
6. Adapt the vision to the target audience.
7. Focus on value for customer and users not on technology
8. Keep your vision short clear and inspiring : a good vision is inspiring for people, it's a description of a dream. It should be for long term.

Exemple For (customer) who (statement of need) the (name of the product) is a (product category) that (key benefit, reason to buy) unlike (competitors) out product (differentiation)

1. Make the vision fit with the company vision and strategy
2. Validate your vision with stakeholders and the scum team : collaborate

aligning Product Vision with Product Value

Si un élément est dépendant de quelque chose, le product owner s'assurera que cette dépendance soit visible dans le Backlog Product.

Il s'assurera qu'il y a assez d'élément prêt et indépendant pour l'équipe de dev.

How to handling emerging priorities not in line with the sprint goal.

• This includes teaching the Product Owner to prioritize new requests in the Product Backlog rather than try to push them into the current Sprint. This includes educating stakeholders about Scrum. This could also mean leveraging management.

• Say NO : Having support from your team when you need to say “not now” is helpful.
• If new work emerges during the Sprint, the Development Team and the Product Owner should negotiate.

• Description: What the goal of the PBI is.
• Value: the Business Value of the PBI as determined by the Product Owner.
• Estimate: the Team needs to estimate the relative effort it will take to move the PBI to Done.
• Order: The Product Owner needs to prioritize PBIs by their relative value

acceptance criteria Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”.

–> acceptance criteria could be test description. So it often include it but not always.

C'est quand on décompose le backlog product item en plus petits éléments. Ces items seront prêt pour un prochain sprint.

Poor Product Backlog refinement causes the “what” to grow during the Sprint. Product Backlogs are not meant to be detailed requirements contracts.

• Consider having the full Scrum Team participate in Product Backlog refinement.
• The goal of refinement is to get Product Backlog Items to an actionable level of detail. You may choose to make this more formal with a Definition of Ready. I like Roman Pichler's description of “ready” as clear, feasible, and testable.
• Refinement is important so that value is understood and achievable. A Product Owner does not have to do all of the refinement activity alone.

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above described refining activities.

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

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog

Product Backlog refinement is a summary of all activities that relate to Product Backlog items.

Backlog refinement (formerly known as backlog grooming) is when the product owner and some, or all, of the rest of the team review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery.

During Backlog Refinement (Grooming) the Scrum Master facilitates as the Product Owner and Scrum Team review the user stories at the top of the Product Backlog in order to prepare for the upcoming sprint. Backlog Refinement (Grooming) provides the first input to Sprint Planning.

A product backlog refinement session provides value in a number of ways: It ensures that the team start to look ahead at upcoming product backlog items, reviewing and revising their content. It allows for any queries over product backlog item content to be raised and answered at an early stage

This is not necessary a meeting but a serie of activities

Every member of the Scrum Team is responsible for Product Backlog Refinement: product owner buit the right thing, dev build the things right and scrum master ensure feeback in empiricism. Every activity that affects the state of the Product Backlog can be seen as refinement.

Definition of Ready”. During Product Backlog refinement, detail, order, and estimates will be added or improved until the work on the backlog meets this condition. scrum:po-questions

• I (Independent). The PBI should be self-contained and it should be possible to bring it into progress without a dependency upon another PBI or an external resource.
• N (Negotiable). A good PBI should leave room for discussion regarding its optimal implementation.
• V (Valuable). The value a PBI delivers to stakeholders should be clear.
• E (Estimable). A PBI must have a size relative to other PBIs.
• S (Small). PBIs should be small enough to estimate with reasonable accuracy and to plan into a time-box such as a Sprint.
• T (Testable). Each PBI should have clear acceptance criteria which allow its satisfaction to be tested.

Il pèse les avantages et inconvénients d'une mise à jour. While Scrum doesn’t require a release to occur every Sprint, it should be noted that the more elapsed time that accumulates since the last release, the higher the risk that the product’s value will get out of line with the marketplace. Product Owners should keep this risk in the forefront of their mind. Another factor in the release decision is whether your customers can actually absorb your frequent releases. Most customers approach this upgrade decision using a common sense method of weighing the costs and benefits of the upgrade(new increment). This is all the more reason to make sure that your releases are of the utmost value, and offer relatively low absorption costs. Regardless of the benefits and costs, some customers will still be constrained, so this constraint should be a consideration when deciding how often or whether to release. The PO is the one and only person who can decide whether to release the latest increment of the product. The Increment is “Done” by its definition.

the PO should do everything in their power to involve key stakeholders in Sprint Reviews to increase feedback Knowine who are the key stakeholder help how to meet market demand, meet the needs of the stakeholders, and generally being able to deliver a high-value product!

Emergence : In Scrum, delivery is releasable software by the end of a Sprint. Emergence implies that all solutions to all problems will become clear as we work, not simply by talking about them.

Challenges Balancing Emergence and Delivery New work is being assigned to the Development Team. The Development Team should be focused on the Sprint Goal and using the Sprint Backlog to visualize progress towards achieving it. Sprint Goal helps the team stay focused and provides flexibility as work emerges.

Il doit tenir compte du risque de non conformité du produit Il doit tenir compte des changement occasionné par la nouvelle version et de l'adaptation des clients. Il doit tenir compte des avantages mais aussi des coûts lié à la mise à jour

Par contre il ne doit pas tenir compte si l'incrément répond ou non à la définition de fini car c'est l'équipe de dev qui devrait faire ce travail

Bien que Scrum n’exige pas de release à chaque Sprint, il convient de noter que plus le temps écoulé s’élève depuis la dernière release, plus le risque que la valeur du produit ne corresponde à celle du marché augmente. Les propriétaires de produits devraient garder ce risque à l'avant-plan de leurs préoccupations. Un autre facteur dans la décision de publication est de savoir si vos clients peuvent réellement absorber vos publications fréquentes. La plupart des clients abordent cette décision de mise à niveau en utilisant une méthode sensée consistant à évaluer les coûts et les avantages de la mise à niveau (nouvelle incrémentation). C’est d’autant plus une raison de s’assurer que vos rejets sont de la plus grande valeur et offrent des coûts d’absorption relativement bas. Quels que soient les avantages et les coûts, certains clients seront toujours soumis à des contraintes. Cette contrainte doit donc être prise en compte lors du choix de la fréquence de publication ou de la publication. Le bon de commande est la seule et unique personne pouvant décider de la publication de la dernière augmentation du produit. L'incrément est “fait” par sa définition.

• Il doit anticiper la productivité de l'équipe
• La définition de ce qui est terminé donne une transparence de ce qui a été fait à la fin de chaque sprint
• Tracking : ? Does the PO keep a burn-up chart of “value points” delivered per Sprint, or is there some other way to guess or measure delivered value?
• Monitoring Progress Toward Goals

At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.

Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.

False. The Product Owner is solely responsible and accountable for the decisions in the Product Backlog. However, the legwork of managing the Product Backlog might be fully delegated to the Development Team, so it is quite possible that the Product Owner might not ever create or write a User Story or Product Backlog Item.

Comment savoir si un produit a du success

• Grâce à ses revenus
• Le client est satisfait
• Impact sur les coûts

Mais ces éléments ne sont pas à prendre en consédérations

• La bonne évaluation des estimations de départ. Ce n'est pas parce que la réalisation est conforme aux estimation que le produit est un success

https://www.scrum.org/resources/scrum-glossary

Technical Debt: the typically unpredictable overhead of maintaining the product, often caused by less than ideal design decisions, contributing to the total cost of ownership. May exist unintentionally in the Increment or introduced purposefully to realize value earlier. One of the ways of handling technical debt is recording it on the Product Backlog. So, it becomes visible to the Scrum Team.

Velocity: an optional, but often used, indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team.

Ready a shared understanding by the Product Owner and the Development Team regarding the preferred level of description of Product Backlog items introduced at Sprint Planning.

acceptance critiria as “Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.” … These criteria define the boundaries and parameters of a User Story/feature and determine when a story is completed and working as expected

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. In other words it can be defined as the longer term consequences of poor design decisions. Technical debt is a real risk which can genuinely be incurred. It compromises long-term quality of the Product. One of the ways of handling technical debt is recording it on the Product Backlog. So, it becomes visible to the Scrum Team.

On peut en parler dans le rafinement et les avoir sur un tableau pour ne pas les oublier. Il faut toujours ajouter des élément ayant de la valeur tout en éliminant la dette technique.

Il ne faut pas faire un sprint spécial pour résoudre la dette technique mais toujours pour livrer un incrément ayant de la valeur.

RAID : Risks, Assumptions, Issues, and Dependencies –> Il faut la mettre dans la définition of done

KVA Key Value Area Evidence-Based Management is a framework organizations can use to help them measure, manage, and increase the value they derive from their product delivery. Organizations invest in agile processes, tools, training, and coaching, but how much are they getting back? Has product delivery improved? How much happier are customers? Are employees satisfied and enabled?

https://www.scrum.org/resources/evidence-based-management

• How do you know if your product is successful and delivers high value?

Interviews? Metrics in the product? Alexa index? More money from stakeholders? Happier employees? Satisfied customers? Competition going out of business?

• LE PO doit travailler sur le long terme et partager la vision, il doit avoir un Product Backlog avec des éléments prêts pour les prochains sprint. Les choses doivent être bien clairs pour tous. Is the PO working reactively (short-term only) or proactively (long-term vision being played out through the ordering of the PBIs in the PBL)? Can the PO motivate short-term vs long-term focus, ie which is the right thing to aim for now?
• Good job ? - metrics - money ? More users ? more leads less bugs.

• Que se passe-t-il si l'incrément ne répond pas à la définition de fini?

https://scrumcrazy.wordpress.com/2018/09/22/the-new-new-product-owner/

SCRUM