Not applicable due to the specifics of the team's work.
Criteria from level 1 are not met or the team does not have OKR for the current quarter, as it has just been formed.
- in 40% of the key results, metrics of the team's products are recorded;
- PM and tech lead hold three OKR events: OKR planning (formulation of KR, setting weights, assessment of achievability), check-in, OKR retrospective;
- the result of achieving OKR for the quarter is from 50 to 65%;
- as a result of the OKR retrospective, the team forms a list of corrective actions.
- in 40-60% of the key results, metrics of the team's products are recorded;
- the entire team participates in three OKR events;
- the result of achieving OKR for the last quarter is from 65 to 80%;
- action items from the last two OKR retrospectives are closed by more than 50%.
- in 60% of the key results, metrics of the team's products are recorded;
- the result of achieving OKR for the last two quarters is from 75%;
- action items from the last two OKR retrospectives are closed by more than 70%.
Not applicable due to the specifics of the team's work.
Criteria from level 1 are not met.
- more than 50% of the tasks at the start of the sprint / cadence correspond to the definition of readiness(DoR) accepted in the company;
- the assessment of the upcoming work at the PBR is given by the immediate performers (developers);
- as a result of the PBR, there is a high-level technical solution developed by the team.
- more than 75% of the tasks at the start of the sprint / cadence correspond to the definition of readiness (DoR) accepted in the company;
- the team adheres to its extended DoR in addition to the company's basic DoR.
- more that 90% of the tasks at the start of the sprint correspond to the definition of readiness (DoR) accepted in the company;
- detailed technical elaboration of tasks is taken out of PBR, carried out in smaller groups, the results are included in the next general PBR.
Not applicable due to the specifics of the team's work.
Criteria from level 1 are not met.
- planning is carried out on the first day of each sprint;
- the team takes into account velocity when planning a sprint;
- the sprint backlog is filled without taking into account the dependencies between tasks.
- planning takes no more than 2 hours for a 2-week sprint;
- the team plans its work for the sprint / cadence based on its current capacity (weekends, holidays, vacations, absences, large meetings, etc.);
- planning takes into account dependencies and mutual blocking between team members;
- the team analyzes the metrics (velocity and scope drop) for the sprint, puts forward hypotheses for their improvement at the retro and turns them into action points.
- The team always takes to the sprint only tasks with closed risks for external dependencies: there is an agreed plan of work with other teams or dependencies are resolved before taking the task into work.
- The team does not work on tasks that are not ready for development (DoR).
Not applicable due to the specifics of the team's work.
Criteria from level 1 are not met.
- the team sets one unifying sprint goal in half of the cases (3 out of 6 sprints per quarter have only one goal);
- from 30 to 50% of the sprint backlog tasks are responsible for achieving the goal;
- from 50 to 80% of the sprint goals for the quarter are achieved.
- the team always sets one unifying sprint goal;
- the tasks at the planning always correspond to the sprint goal, and not vice versa;
- more than half of the sprint goals for the quarter affect the achievement of OKR;
- more than 50% of the sprint backlog tasks are responsible for achieving the goal;
- 80% of the sprint goals for the quarter are achieved.
- the sprint goal is always formulated as closing a user need or improving a metric;
- OKR are used to formulate 85%+ of sprint goals;
- 70% of the sprint backlog tasks are responsible for achieving the goal;
- 90% of the sprint goals for TWO quarters are achieved.
Not applicable due to the specifics of the team's work.
Criteria from level 1 are not met.
- all team members regularly conduct and participate in the sync meeting (standup) at the same time. The meetings are cancelled only if the facilitator is absent;
- the team members voice task blockers at the standup;
- the board is not always updated before the standup.
- by the beginning of the standup, the board is always up-to-date;
- the standup is always held. Even in the absence of the facilitator, the team does not cancel the standup;
- the standup is not a status meeting. The team discusses only how to effectively move towards the sprint goal and what prevents it;
- the team always comes out of the meeting with action points to eliminate blockers.
- each team member periodically conducts a standup;
- the meeting takes no more than 15 minutes;
- the board and task statuses are updated immediately at the time of changes without being tied to the standup.
Not applicable due to the specifics of the team's work.
Criteria from level 1 are not met.
- the team has a meeting for reviewing the increment and collecting feedback in the calendar;
- the demo of the increment is most often conducted by the PM or tech lead / platform owner.
- each team member shows the increment for the sprint / cadence at the review;
- there are key stakeholders at the meeting;
- as a result of the review, there is an updated product backlog taking into account the feedback received.
As a result of the review, the team and key stakeholders synchronize their backlogs with each other.
Not applicable due to the specifics of the team's work.
Criteria from level 1 are not met.
- the team has a regular retrospective to analyze the past sprint;
- the entire team is present at the retrospective;
- as a result of the retro, there are action points, for which a responsible person and deadlines are assigned.
- the team analyzes the performance metrics of the last sprint (at the retro or other team event);
- action points are completed on time in more than half of the cases.
- Retrospectives are regularly held by each team member.
- Action points are always completed on time. The discussed problems are not repeated from retro to retro.
Not applicable due to the specifics of the team's work.
Criteria from level 1 are not met.
- the team has a documented social contract;
- all subject areas and areas of responsibility of the team are clearly documented in the social contract.
- each new team member is familiar with the social contract during onboarding;
- the social contract was last updated or revised no later than six months ago;
- more than half of the critical subject areas and areas of responsibility are covered by at least two team members.
- the team members use the social contract to give open feedback to each other;
- expertise in each critical subject area and area of responsibility of the team is closed by at least two team members.
Not applicable due to the specifics of the team's work.
- the team is not a cross-functional team and cannot independently implement one product;
- more than half of the expertise is outside the team.
- the team has expertise to implement the product from the Pre-Delivery stage to the release;
- the team regularly checks the performance and quality metrics. Each team member can name at least three key metrics from this group.
- the team independently develops functionality from validating a hypothesis to rolling out to production. Involves external experts or consultants in the process of creating value if it finds a lack of expertise / competence to deliver functionality;
- the team regularly checks its performance, quality and tech metrics. Corrects processes or performs tasks to fix anomalies in metrics and / or advance the value in the right direction.
- the key stakeholders are involved in the process of setting goals and rolling out features developed by the team.;
- the team regularly checks the product metrics. There is a regular event or other form where the team gets an overview of the key metrics of the product it is working on.