Jak je role PO a kdo by to

• • • Jaká je role PO a kdo by to měl v Komixu být? Co znamená samo-organizovaný tým? Jak velký má tým být? Co má být v produktovém backlogu? Co si představit jako výsledek sprintu? Jak moc trvat na tom, že výsledek sprintu je uchopitelný a prezentovatelný? • Jak by měl fungovat denní Scrum, Planning, review, retrospektiva? • Jak často by měla být retrospektiva a jaký je její účel? • Jaké jsou formáty retrospektivy? • Co je backlog refinement? • Jak dělat odhady a co jsou story pointy?

Scrum a brief introduction Jiří Täuber 10. 11. 2020

Why? The purpose of this document and training material is for us to: • Have a common vocabulary • Understand theory some of us try to apply in their work • Know how theory applies in our environment

Agenda • Introduction • Roles • Artifacts • Processes • Review

Tools, Methodologies and Frameworks • Dual track Agile • Kanban • Lean • Scrum • Less • Nexus • SAFe • Scrum of Scrums

What is Scrum is a framework for developing and sustaining complex products https: //www. scrumguides. org/

Products or Projects Product Project • Relatively long life cycle • Clear start and end • Vision and purpose • Defined scope and budget • Needs to be sustained and updated • Acceptance/delivery criteria • Success is evaluated continuously • Success depends on the acceptance

What is Scrum is a framework for developing and sustaining complex products The definition consists of Scrum’s Employs an iterative, incremental approach to optimize predictability and control risk. • Roles • Artifacts Three pillars uphold every implementation of empirical process control: • Events • Transparency • The rules that bind them together • Inspection • Adaptation

Roles

Scrum Team

The sole person responsible for managing the Product Backlog • • Clearly expressing PBIs (titles, descriptions, …) Ordering the items in the Product Backlog Optimizing the value of the work the Dev. Team performs Ensuring that the Product Backlog is visible, transparent, and clear to all • Ensuring the Development Team understands items in the Product Backlog to the level needed PO is responsible for maximizing the value of the product. The PO is one person. Those wanting to change a Product Backlog item’s priority must address the PO. The PO may do this work, or have the Dev. Team do it. The PO remains accountable.

Managing the Product Backlog may be a group effort. • • Clearly expressing PBIs (titles, descriptions, …) Ordering the items in the Product Backlog Optimizing the value of the work the Dev. Team performs Ensuring that the Product Backlog is visible, transparent, up-to-date, and clear to all • Ensuring the Development Team understands items in the Product Backlog to the level needed There may be more Analysts but only one PM PO is responsible for priority and scope decisions Keep the project scope in mind, everyone is responsible for on-time delivery Analysts define the scope of PBIs and often even priority Final accountability belongs to the PM

Development Teams are: • Self-organizing - No one tells them how to turn PBIs into potentially releasable functionality • Cross-functional – with all the skills as a team necessary to create a product Increment • Without titles for Dev Team members – regardless of the work being performed by the person • Without sub-teams - regardless of domains that need to be addressed (testing, development, or analysis) Organize and manage their own work to optimize their efficiency and effectiveness Consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint Small enough to remain nimble Large enough to complete significant work within a Sprint

Communication Helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. Helps everyone change these interactions to maximize the value created by the Scrum Team. Servant-leader for the Scrum Team Responsible for promoting and supporting Scrum Helps everyone understand Scrum theory, practices, rules, and values

The SM serves the PO in several ways • Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team • Finding techniques for effective Product Backlog management • Helping the Scrum Team understand the need for clear and concise Product Backlog items • Product planning in an empirical environment • Ensuring the Product Owner knows how to arrange the Backlog to maximize value • Understanding and practicing agility • Facilitating Scrum events as requested or needed

The SM serves the Dev. Team • Coaching the Development Team in • Self-organization • Cross-functionality • Organizational environments in which Scrum is not yet fully adopted and understood • Helping the Development Team to create high-value products • Removing impediments to the Development Team’s progress • Facilitating Scrum events as requested or needed

The SM serves the Organization in several ways including: • Leading and coaching the organization in its Scrum adoption • Planning Scrum implementations within the organization • Helping employees and stakeholders understand enact Scrum • Causing change that increases the productivity of the Scrum Team • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization

No dedicated Scrum Masters internally in Komix Od. S Agile • Joins together Agile enthusiasts and evangelists • Helps teams on their journey to be more agile • Supports teams with suggestions of Scrum methods and experience with them Usually supplied by the PM of the team Strive to promote and support Scrum May also be other Scrum evangelists within the team and outside Help everyone understand Scrum theory, practices, rules, and values

Artifacts

Product Backlog • An ordered list of everything that is known to be needed in the product • Constantly changing to identify what the product needs to be appropriate, competitive, and useful. • The single source of requirements for any changes to be made to the product. No one can force the Development Team to work from a different set of requirements. Product Backlog items have the attributes of • description, order, estimate, value • often include test descriptions that will prove its completeness when "Done" (acceptance criteria) • The PO is responsible for the Product Backlog, including its content, availability, and ordering. • Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.

Product Backlog • An ordered list of everything that is known to be needed in the product or project • Mostly growing as analysis continues and defines new use cases • May include also analytical, technical, architectural, documentation, UAT and release-related work (each PBI should still have a clear output) • The single source of requirements for any changes to be made to the product Product Backlog items have the attributes of • description, order, (estimate), value If there is no dedicated PO • The PM is responsible for the priorities because he is responsible for the final delivery of each project milestone • The PM often delegates priority decisions to analysts (implicitly or explicitly) • Analysts then organize the backlog according to the expected project roadmap

Monitoring progress At any point in time, the total work remaining to reach a goal can be summed. Various projective practices upon trending have been used to forecast progress, like: • The PO tracks this total work remaining at least every Sprint Review. • burn-downs • The PO 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. • 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 forward-looking decision-making.

Sprint Backlog • Belongs solely to the Development Team • Is the set of Product Backlog items selected for the Sprint + a plan for delivering the product Increment and realizing the Sprint Goal • Makes visible all the work that the Dev Team identifies as necessary to meet the Sprint Goal • Includes at least one high priority process improvement identified in the previous Retrospective meeting • Is a highly visible, real-time picture of the work that the Dev Team plans to accomplish during the Sprint with enough detail that changes in progress can be understood in the Daily Scrum • As new work is required (necessary to meet the Sprint Goal), the Dev Team adds it to the Sprint Backlog • As work is performed, the estimated remaining work is updated; unnecessary items are removed • The Dev Team tracks the total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal

Sprint Backlog • Belongs solely to the Development Team • Is the set of Product Backlog items selected and committed for the Sprint + a (more or less specific) plan how to deliver them • Makes visible all the work that the Dev Team identifies as doable within the sprint timebox • Sometimes includes a process improvement identified in the previous Retrospective meeting • Is a highly visible, real-time picture of the work that the Dev Team is currently working on • As new work is required, the Dev Team adds it to the Sprint Backlog • As work is performed, the estimated remaining work is updated; unnecessary items are removed • The Dev Team tracks the total work remaining at least for every Daily Scrum to project the likelihood of completing the Sprint

Increment • Is the sum of all the PBIs completed during a Sprint + the value of the increments of all previous Sprints • Is a body of inspectable, done work that supports empiricism at the end of the Sprint • Is a step toward a vision or goal • At the end of a Sprint, the new Increment must be "Done“ • Must meet the Scrum Team’s Do. D • Must be in useable condition regardless of whether the PO decides to release it or not

Definition of Done When a PBI or an Increment is described as "Done", everyone must understand what "Done" means. Everyone must have a shared understanding of what it means for work to be complete, to ensure transparency. • The Development Team of the Scrum Team must define a Do. D appropriate for the product • Any one product or system should have a definition of "Done" that is a standard for any work done on it • If there are multiple Scrum Teams working on the system or product release, then the Dev Teams on all the Scrum Teams must mutually define the Do. D • If the Do. D for an Increment is part of the organization’s conventions, standards or guidelines, then all Scrum Teams must follow it as a minimum. • The Do. D is used to assess when work is complete • The Do. D guides the Dev Team in knowing how many PBIs it can select during a Sprint Planning

Bonus: Sprint Goal • The Sprint Goal is an objective set for the Sprint that can be met through the implementation of PBIs • The selected PBIs deliver one coherent function, which can be the Sprint Goal • Provides guidance to the Dev Team on why it is building the Increment • The Sprint Goal can be any other coherence that causes the Dev Team • To work together • rather than on separate initiatives • It is created during the Sprint Planning meeting • It gives the Dev Team some flexibility regarding the functionality implemented within the Sprint As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

Bonus: Sprint Goal

Processes

The Sprint • Time-box of one month or less • "Done", useable, and potentially releasable product Increment is created during the Sprint • Sprints contain and consist of: • Sprint Planning • Daily Scrums • The development work • Sprint Review • Sprint Retrospective • Sprints are used to accomplish something. Each Sprint has: • A goal of what is to be built • A design • A flexible plan that will guide building it • The work • The resultant product increment • During the Sprint: • Quality goals do not decrease • No changes are made that would endanger the Sprint Goal • Scope may be clarified and re-negotiated between the PO and Development Team as more is learned Sprints enable predictability and limit risk by inspection and adaptation of progress toward a Sprint Goal

The Sprint scope may be renegotiated during the sprint but must not endanger the sprint commitment. Two week sprints One week sprints • Most common in Komix as well as other companies • Provide faster learning cycle • Good balance between frequent delivery and planning overhead • Recommended when • Project starts • The Scrum Team is (re)forming • The Dev. Team needs to quickly improve planning, delivery, release or other processes • Faster response to requirements is needed • Good for delivering most projects • Not ideal for short-term or highly volatile projects • Longer sprints are also possible when scope is clear SLAs and other fast reaction ad-hoc requirements do not fit into sprints, capacity should be reserved for them

Sprint Planning • The work to be performed in the Sprint is planned at the Sprint Planning • The 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 • The Scrum Master ensures that the event takes place and that attendants understand its purpose • Sprint Planning answers the following: • What can be delivered in the Increment resulting from the upcoming Sprint? • How will the work needed to deliver the Increment be achieved?

Topic One: What can be done? The entire Scrum Team collaborates on understanding the work of the Sprint • The input to this meeting is: • The Product Backlog • The latest product Increment • Projected capacity of the Development Team during the Sprint • Past performance of the Development Team • The PO discusses the objective that the Sprint should achieve and the PBIs that would achieve the Sprint Goal • The number of selected PBIs for the Sprint is solely up to the Development Team; Only the Development Team can assess what it can accomplish over the upcoming Sprint • During Sprint Planning the Scrum Team also crafts a Sprint Goal

Topic Two: How will the work get done? The Dev Team decides how it will build the selected functionality into a "Done" Increment during the Sprint • The input to this meeting is: • The Sprint Goal • The selected the PBIs for the Sprint • The PBIs selected for this Sprint plus the plan for delivering them is called the Sprint Backlog • Work for the first days of the Sprint is decomposed by the end of this meeting, to units of one day or less • The PO can help to clarify the selected PBIs and make trade-offs • The Development Team may also invite other people to attend to provide technical or domain advice By the end of the Sprint Planning, the Dev Team should be able to explain to the PO and Scrum Master how it intends to work to accomplish the Sprint Goal and create the anticipated Increment.

Sprint Planning • Analysts and PM lead the planning meeting and help with scope and priority decisions • Sprint backlog usually has a clear outline even before the planning (see refinement) • The sprint plan is finalized by the collaborative work of the entire Scrum Team • Sprint Planning is about 2 hours long for 2 -week sprint • Sprint Planning answers What can be delivered = which PBIs will be done at the end of the upcoming Sprint • Sprint planning often misses: • Sprint goal with some flexibility regarding the functionality implemented within the Sprint • Clear commitment to deliver the discussed scope made by the whole Development team • Plan how to deliver the committed scope of the sprint backlog • At least one high priority process improvement included in the sprint backlog

Daily Scrum • 15 -minute time-boxed event for the Development Team • Held every (work)day of the Sprint at the same time and place each day to reduce complexity • The Dev Team inspects: • Progress toward the Sprint Goal • How progress is trending toward completing the work in the Sprint Backlog • The Development Team plans work for the next 24 hours and forecasts the upcoming Sprint work • The structure of the meeting is set by the Dev Team and can be conducted in different ways but it always focuses on progress toward the Sprint Goal • The Scrum Master • Ensures that the Dev Team has the meeting, but the Dev Team is responsible for the Daily Scrum • Ensures that people outside the Dev Team do not disrupt the meeting if present

Sprint Review • An informal meeting held at the end of the Sprint • Attendees include the Scrum Team and key stakeholders invited by the PO • The entire group inspects the "Done" Increment; the presentation should elicit feedback • The PO explains what PBIs have been "Done" and what has not been "Done" • The Dev Team demonstrates the work that it has "Done" and answers questions • The PO discusses the Product Backlog as it stands • The PO projects likely target and delivery dates based on progress to date (if needed) • They also adapt the Product Backlog if needed • The entire group collaborates on what to do next as an input to subsequent Sprint Planning • Review of the timeline, budget, potential capabilities, and marketplace for the next releases • The result of the Sprint Review is a revised Product Backlog that defines the likely PBIs for the next Sprint

Sprint Review • An internal meeting held at the end of the Sprint – mostly only the Scrum Team • The team demonstrates the "Done" Increment; the presentation should be on a live product • The Scrum Team reviews the result of the sprint • The Dev. Team reviews which PBIs have been "Done" and what has not been "Done“ • The whole Scrum Team discusses the current state of the product (bugs, etc. ) • The PO/PM reviews progress towards project milestones based on progress to date • The whole group decides what to do with unfinished PBIs and cleans the Sprint Backlog • They also adapt the Product Backlog if needed • The entire group collaborates on what to do next as an input to subsequent Sprint Planning • Review of the timeline, budget, potential capabilities, and requirements for the next releases • The result of the Sprint Review is a closed Sprint Backlog and a revised Product Backlog

Sprint Retrospective • Opportunity for the Scrum Team to inspect itself and create a plan for improvements • Occurs after the Sprint Review and prior to the next Sprint Planning • The Scrum Master participates as a peer team member and ensures that the meeting is positive and productive • The purpose of the Sprint Retrospective is to: • Inspect how the last Sprint went with regards to people, relationships, process, and tools • Identify and order the major items that went well and potential improvements • Create a plan for implementing improvements to the way the Scrum Team does its work • Improve the development process and practices to make it more effective and enjoyable • Plan ways to increase product quality by improving processes or adapting the Do. D Improvements may be implemented at any time, the Sprint Retrospective only provides a formal opportunity to focus on inspection and adaptation and identify improvements that will be implemented in the next Sprint.

Bonus: Product Backlog Refinement • The act of adding detail, estimates, and order to PBIs • More precise estimates are made based on the greater clarity and increased detail • An ongoing process in which the PO and the Dev Team collaborate on the details of PBIs • The Scrum Team decides how and when refinement is done • Refinement usually consumes no more than 10% of the capacity of the Dev Team • PBIs can be updated at any time by the PO or at the PO’s discretion (not changing scope during a Sprint) • Opportunity to review and revise (potentially remove) PBIs that will occupy the Dev Team for the upcoming Sprint are refined so that any one item can reasonably be "Done" within the Sprint time-box; such PBIs are deemed “Ready“ for selection in a Sprint Planning

Bonus: Product Backlog Refinement • Rarely happening as a separate event with dedicated time • The PO/PM almost never attends – should be invited as an arbiter to scope decisions • The PO/PM should approve the scope (description and acceptance criteria) during the meeting or afterwards • The Scrum Master can be invited to help facilitate the meeting Do. R Do. D • PBI = anything that is known to be needed in the product • Definition of Ready = When is the PBI ready for development • Definition of Done = When is the PBI / Increment ready for release

Detail: Estimations and Velocity The Development Team is responsible for all estimates. The PO/PM may influence the Development Team by helping it understand select trade-offs, but the people who will perform the work make the final estimate. Estimates can be in • Man-hours / man-days • Story points • T-shirt sizing, Cargo size, … • No estimates Story points • Modified Fibonacci scale: 1, 2, 3, 5, 8, 13, 20, 40, . . . • Compare PBIs to one another • Combine effort, complexity and risk • Are independent on who is doing the work The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint. Accountability belongs to the Dev Team as a whole.

Inspect & Adapt Inspect Adapt Inspect

End Note What is Scrum and what is not • Scrum is free and offered in the Scrum Guide • Scrum’s roles, events, artifacts, and rules are immutable • Implementing only parts of Scrum is possible, however the result is NOT Scrum • Scrum exists only in its entirety • Scrum functions well as a container for other techniques, methodologies, and practices

Questions? KOMIX s. r. o. Drtinova 467/2 a 150 00 Praha +420 257 288 211 recepce@komix. cz IČ: 47117087 DIČ: CZ 47117087 Společnost je registrována u rejstříkového soudu v Praze, oddíl C, číslo vložky 12440.