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.
Make sure every body understand the challenge of refinement
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
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.
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)
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.
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.
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
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.
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
Mais ces éléments ne sont pas à prendre en consédérations
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?
| Current Value | Measures value delivered to customer or user today - la valeur aujourd'hui |
| Unrealized Value | Measures value that could be realized by meeting all potential needs of the customer or user - La valeur potentielle |
| Ability to Innovate | Measures the ability to deliver a new capability that might better serve a customer or user need - inovation |
| Time to Market | Measures the ability to quickly deliver new capability, service, or product- rapidité à venir |
Interviews? Metrics in the product? Alexa index? More money from stakeholders? Happier employees? Satisfied customers? Competition going out of business?