3 ROLES:
PRODUCT OWNER:
Our Product Owner role prioritizes the work for their Scrum team. If the organization does not have difficulty building the right thing, negotiating alignment on what the right thing is across many stake holders, and continuously changing the next thing to be the most valuable option, then the Product Owner role is not needed as it is being accomplished in another way. The input to a successful product owner is many options of what the team may learn to build and estimates of the business value and effort of those options. This list of possibilities to consider is our first recommended Accessory to Scrum, the Not Ready list. The Not Ready list is a column on the team’s Scrum board where possible projects, products, or services are listed to be considered by the product owner but not yet prioritized by technical dependency, value, and relative effort. The output from a successful product owner is the Product Backlog, a single, prioritized, ordered list where at least the top sprint’s worth of work meets the team’s Definition of Ready, our second recommended Accessory to Scrum. The Definition of Ready is an agreement, typically on a virtual poster on the Scrum Board, where the team commits that any product backlog item that meets the Definition of Ready is likely to be completed within a single sprint. Let’s summarize what the Product Owner takes in and puts out to be successful:
Input: Backlog Not Ready Column.
Output: Product Backlog that meets the Definition of Ready.
SCRUM MASTER:
If the organization is consistently and visibly increasing in speed, quality, and psychological safety, and the value of the 5 events of Scrum as listed below is achieved, the scrum master role may be omitted as the value of the Scrum Master role is already being achieved in another way. The Scrum master observes a Scrum Team working, this the input to a Scrum Master, direct observation and likely participation in the work of the Sprint Backlog. Their primary output is kaizen, or specific business and psychologically positive work items to systematically improve the speed, well-being, and capability of the team. These kaizen cards are executed immediately without disrupting the team or placed in the team’s Not Ready list to be prioritized into the Product Backlog or Sprint Backlog as soon as responsible. A second output of the Scrum Master is a big visible Scrum Board, creating the known stable interface between Scrum Teams and allowing many teams to work together fast and effectively in Group Scrum. The third output of a Scrum Master is facilitating the 5 events of Scrum, or ensuring that the outputs of the 5 events of Scrum are fulfilled another way. There are Scrum Accessories that the Scrum Master is likely to also output, and practicing them will improve a team’s responsiveness to business opportunities.
Let’s summarize the inputs and outputs of the Scrum Master role to clarify:
Input: observing or likely participating in the work of a Scrum Team.
Output: Kaizen, or systematic business driven continuous improvement in speed and psychological safety.
Output: Visible team speed, quality, psychological well-being indicator, and trends answering the questions “well will be done”.
Output: Facilitating the 5 events of Scrum or verifying the value of the 5 events is being achieved another way.
DEVELOPMENT TEAM:
The Development Team are the people or robots and automated process that do the work. Whatever mechanism is completing the work is the Development Team, and the performance of that Development Team is measured by the rate the input, here called “ready backlog”, is brought to the output, here called “product increment” which is shown at Sprint Review to meets the Definition of Done and any listed Acceptance Criteria. The Development Team takes as an input the Product Backlog that meets the Definition of Ready. They then create the Sprint Backlog, their best near-term list of experiments to achieve the top item on the Product Backlog, which is also referred to as the Sprint Goal, or the increment we will observe the team’s customer and automated tests use at the end of the sprint during the Sprint Review event. Achieving the top item on the Product Backlog explicitly means meeting any Acceptance Criteria listed on the Product Backlog Item and meeting the team’s Definition of Done, a recommended Scrum Accessory which is typically a virtual poster on the team’s Scrum Board stating what quality means for this team when the team moves a card on their Scrum Board to “Done”.
Input: Product Backlog that meets the Definition of Ready.
Output: Sprint Backlog showing changeable plan to meet the Definition of Done for one or more Product Backlog Items.
Output: Product Backlog Items that meet the Definition of Done and any listed Acceptance Criteria.
5 EVENTS OR MEETINGS:
SPRINT: If the products and goals are consistently being met when expected, on time and on budget, and the people doing the work have a fast feed-back loop of any problems found in their work, the Sprint may be omitted. The sprint is the shortest amount of time the team can completely deliver products, services, or goals, and receive feedback on how effectively they completed their mission. This is often not understood, a sprint cannot end if the product has not completed all design, assessment, quality, funding, testing, and qualification phases or reviews. If this is difficult, please consider our Certified Scrum Master and then Certified Scrum Product Owner seminars.
Input: Product Backlog that meets the Definition of Ready.
Output: One or more Product Backlog Items that meets the Definition of Done and any listed Acceptance Criteria.
SPRINT PLANNING: If a team is consistently succeeding in delivering completed missions and goals to their customer within the sprint length, the team may omit Sprint Planning. Sprint Planning is the shortest meeting possible for the people doing the work to communicate to the people who want the work done how much is likely to meet the quality bar by the end of the sprint, and for the people doing the work to create the initial plan of how the work will be approached.
Input: Product Backlog that meets the Definition of Ready.
Output: A sprint backlog that the Development Team and the Product Owner agree is likely to be completed, entirely meeting the Definition of Done and any listed Acceptance Criteria, within the agreed Sprint length.
DAILY SCRUM: If the people doing the work are already aware of what is in work, what is next, and what is blocked, and already aware of how to help each other in order to find the fastest responsible engineering practices and automation, the Daily Scrum may be omitted. The Daily Scrum is the shortest meeting possible to replan the day’s work for optimum output.
Input: status of what is done, what is in work, what is out for an external dependency, and any other updates to the Scrum Board.
Output: A plan for the day to make the most progress responsible in the healthiest, sustainable way.
SPRINT REVIEW: If psychological safety is high, and the development team is already receiving real-world user feedback within days of having completed a piece of work, and that feedback is being used to reprioritize which work to be done next and improve how that work item is attempted, the Sprint Review may be omitted. The Sprint Review is the shortest meeting practical for the people doing the work to explain how much of the Product Backlog they are statistically likely to bring to the Definition of Done within the next sprint, and create their initial plan to accomplish that.
Input: One or more Product Backlog Items that meets the Definition of Done and any listed Acceptance Criteria.
Output: Observation of a real or simulated user trying to use the Product Backlog Item produced. This step is frequently misunderstood, Product Backlog Items are used by the customer in Sprint Review, if the sprint did not produce something interesting for the customer the Sprint was too short for the team’s current level of automation and engineering practices.
SPRINT RETROSPECTIVE: If the people doing the work are consistently increasing speed without reducing quality, and psychological safety and well-being measures are adequate and increasing, the sprint retrospective may be omitted. The Sprint Retrospective is the shortest meeting practical to increase psychological safety and increase the speed and happiness of the team without deteriorating quality.
Input: Observation of the Sprint Review and the daily work of the last sprint.
Output: One kaizen, or continuous improvement initiative, to increase speed or happiness, committed to be completed within the next sprint and within the budget or capability of the Scrum Team.
3 OUTPUTS OR ARTIFACTS:
PRODUCT BACKLOG: If the Priority of what is highest value to work on is understood consistently by the people doing the work and the people who want the work done, and multi-tasking is minimal or non-existent, the Product Backlog may be omitted. The Product Backlog is a single ordered list of approximately sprint-sized projects, products, or services.
INPUT: Backlog Not Ready column, or list.
OUTPUT: The top of the product backlog is pulled into the Sprint Backlog by the Development Team during the Sprint Planning Event.
SPRINT BACKLOG: If the team is not having difficulty staying focused and not having issues with scope creep or other projects creating multitasking, a sprint backlog may not be needed as the purpose of the Sprint Backlog is being accomplished another way. A sprint backlog is a loose plan of how the Development Team believes they can bring the top Product Backlog Item to meet the Definition of Done and any listed Acceptance Criteria, within the sprint length, and have that success demonstrated within the Sprint Review.
POTENTIALLY SHIPPABLE PRODUCT INCREMENT: If the team hands their customer completed quality work at each sprint end, and the customer can leave with that work and use it, this output is being achieved. Note that an agile team that is not able to show the current product increment in process at any time has likely stalled in their progress, is confused, or otherwise has delivery risk. Also please note that a Product Increment almost always builds on previous Product Increments, and must be tested and evaluated as working with quality when integrated with previous increments and other likely real world products. This integration testing is part of the sprint and typically shown working as part of Sprint Review.
SCRUM ACCESSORIES:
NOT READY: A column or list just to the left of the Product Backlog where options for future work can be placed for consideration.
PRODUCT BACKLOG REFINEMENT: A meeting, or activity, where everyone helpful brings items in the Not Ready column to meet the Definition of Ready where it can be prioritized into the Product Backlog.
DEFINITION OF READY: A virtual poster, just to the left of the Not Ready column, stating what the Development Team agrees is a minimum amount of clarity and business alignment for a given Product Backlog Item to be low enough risk that they believe they have 80% or higher likelihood of completing that work within a sprint.
BLOCKED BOX: A place to put work that is waiting on an external dependency, such as another team or a vendor or a robotic process outside the team’s control.
DEFNITION OF DONE: The team’s commitment of the quality standard any work they put on their Wall of Done must meet.
WALL OF DONE: Columns for each sprint, scrolling back 4 sprints or more, showing what met the definition of done and was accepted by the team’s customer in each of the previous sprints.
TEAM WORKING AGREEMENT: A virtual poster, typically above the Sprint Backlog, stating how the Development Team members know who is on the team and their agreed behaviors. The list is typically less than 10 items to keep in memorable and useable.
SPRINT BURN DOWN CHART: A timed chart showing what met the Definition of Done and when during the sprint, with a forward trend line showing how much additional effort is likely to be completed before the sprint timebox ends. Burn Up charts are also perfectly recommended when we want to increase scope, such as attracting new projects and clients. Sprint Burn Down charts more quickly answer the question of when a particular scope will be completed, and are recommended when a specific scope is valuable if completed as soon as responsible.
RELEASE BURN DOWN CHART: A timed chart showing what met the Definition of Done and when during the current and any previous Sprints that worked on increments towards a larger product. For example, a modern car has thousands of parts. If the Development team is improving 20 parts per sprint on average with a Definition of Done of backwards compatibility, increased yield, faster production time, and lower cost, the Release Burn Down Chart will show a trend line to when all parts in production for the car are now meeting the new Definition of Done.
PERSONAS: Virtual Posters, typically just to the right of the Wall of Done, showing who are the likely or anticipated users, purchasers, maintainers, purchase influencers, internal stakeholders who fund or can influence the project, and regulatory compliance officials gating product release or use. Each persona displays a short name, a picture of the persona or their archetype, a short list of what they want from the product or service being built and what they don’t like or cause frustration related to the product or service being built. These Personas are used to assess value, create backlog to delight each persona to mitigate risk, group backlog to maximize persona engagement and support at the optimum timing, and eliminate scope that does not maximize the benefit to any of the personas.
RELATIVE SIZE ESTIMATION REFERENCES: Reference projects that the team is familiar with or ideally has recently completed allow the team to quickly and accurately (see our 6 year research study results examined in our Certified Scrum Master seminar) group future projects by effort and complexity relative to the references. Then by timing the completion time to the full Definition of Done and any listed Acceptance Criteria we can create a forward trend of when similar or even different sized projects are likely to be fully complete as well, and see if the team is speeding up or slowing down. The later point is often used to assess if additional automation or robotic support is increasing team speed. In practice, this is often a Small effort + complexity project and a Large effort + complexity project near the Not Ready column.
RELATIVE VALUE ESTIMATION REFERENCES: Reference projects are grouped by how much money they ultimately made or impact they ultimately created towards the company mission, plus risks reduced, plus new capabilities learned and practiced. This creates a value score. For the complete training in the methods of reliably obtaining the value score please see our Certified Scrum Product Owner seminar. Reference Projects labeled with value allow the people who want the work done to quickly assess rough value to the company, divide that by the relative level of effort supplied by the people who do the work, and then order the highest value, lowest effort work first after considering technical dependency. In practice, this is often a Small value and Large value project posted near the Not Ready column.
GROUP SCRUM BOARD: A large virtual board with a row for each team doing work and a column for each sprint going back to the first sprint each team was measured to have completed. Each cell of this grid shows the necessary KPI’s to run the entire business. In practice, these KPI’s are typically how much money or resource did each team consume in that sprint, how much money or resource did the output of that sprint make for the company (and if this is unknown, which is a tragically common problem, we typically have an immediate and severe problem with that team), how many points of effort that team completed in that sprint, any quality problems or quality score with their output that sprint, and what specifically was completed that sprint (the actual Product Backlog Items).
NEXT STEPS
Thank you for reading this fairly technical list of what Scrum actually is, how each piece works together, when to responsibly skip a piece of the 3-5-3 of Scrum, and which Scrum Accessories are recommended first and where they fit into the 3-5-3 of Scrum. Comments, corrections, compliments, and feedback are warmly welcomed. Now let’s make some worthwhile products really, really quickly as part of healthy and positive teams.
PRODUCT OWNER:
Our Product Owner role prioritizes the work for their Scrum team. If the organization does not have difficulty building the right thing, negotiating alignment on what the right thing is across many stake holders, and continuously changing the next thing to be the most valuable option, then the Product Owner role is not needed as it is being accomplished in another way. The input to a successful product owner is many options of what the team may learn to build and estimates of the business value and effort of those options. This list of possibilities to consider is our first recommended Accessory to Scrum, the Not Ready list. The Not Ready list is a column on the team’s Scrum board where possible projects, products, or services are listed to be considered by the product owner but not yet prioritized by technical dependency, value, and relative effort. The output from a successful product owner is the Product Backlog, a single, prioritized, ordered list where at least the top sprint’s worth of work meets the team’s Definition of Ready, our second recommended Accessory to Scrum. The Definition of Ready is an agreement, typically on a virtual poster on the Scrum Board, where the team commits that any product backlog item that meets the Definition of Ready is likely to be completed within a single sprint. Let’s summarize what the Product Owner takes in and puts out to be successful:
Input: Backlog Not Ready Column.
Output: Product Backlog that meets the Definition of Ready.
SCRUM MASTER:
If the organization is consistently and visibly increasing in speed, quality, and psychological safety, and the value of the 5 events of Scrum as listed below is achieved, the scrum master role may be omitted as the value of the Scrum Master role is already being achieved in another way. The Scrum master observes a Scrum Team working, this the input to a Scrum Master, direct observation and likely participation in the work of the Sprint Backlog. Their primary output is kaizen, or specific business and psychologically positive work items to systematically improve the speed, well-being, and capability of the team. These kaizen cards are executed immediately without disrupting the team or placed in the team’s Not Ready list to be prioritized into the Product Backlog or Sprint Backlog as soon as responsible. A second output of the Scrum Master is a big visible Scrum Board, creating the known stable interface between Scrum Teams and allowing many teams to work together fast and effectively in Group Scrum. The third output of a Scrum Master is facilitating the 5 events of Scrum, or ensuring that the outputs of the 5 events of Scrum are fulfilled another way. There are Scrum Accessories that the Scrum Master is likely to also output, and practicing them will improve a team’s responsiveness to business opportunities.
Let’s summarize the inputs and outputs of the Scrum Master role to clarify:
Input: observing or likely participating in the work of a Scrum Team.
Output: Kaizen, or systematic business driven continuous improvement in speed and psychological safety.
Output: Visible team speed, quality, psychological well-being indicator, and trends answering the questions “well will be done”.
Output: Facilitating the 5 events of Scrum or verifying the value of the 5 events is being achieved another way.
DEVELOPMENT TEAM:
The Development Team are the people or robots and automated process that do the work. Whatever mechanism is completing the work is the Development Team, and the performance of that Development Team is measured by the rate the input, here called “ready backlog”, is brought to the output, here called “product increment” which is shown at Sprint Review to meets the Definition of Done and any listed Acceptance Criteria. The Development Team takes as an input the Product Backlog that meets the Definition of Ready. They then create the Sprint Backlog, their best near-term list of experiments to achieve the top item on the Product Backlog, which is also referred to as the Sprint Goal, or the increment we will observe the team’s customer and automated tests use at the end of the sprint during the Sprint Review event. Achieving the top item on the Product Backlog explicitly means meeting any Acceptance Criteria listed on the Product Backlog Item and meeting the team’s Definition of Done, a recommended Scrum Accessory which is typically a virtual poster on the team’s Scrum Board stating what quality means for this team when the team moves a card on their Scrum Board to “Done”.
Input: Product Backlog that meets the Definition of Ready.
Output: Sprint Backlog showing changeable plan to meet the Definition of Done for one or more Product Backlog Items.
Output: Product Backlog Items that meet the Definition of Done and any listed Acceptance Criteria.
5 EVENTS OR MEETINGS:
SPRINT: If the products and goals are consistently being met when expected, on time and on budget, and the people doing the work have a fast feed-back loop of any problems found in their work, the Sprint may be omitted. The sprint is the shortest amount of time the team can completely deliver products, services, or goals, and receive feedback on how effectively they completed their mission. This is often not understood, a sprint cannot end if the product has not completed all design, assessment, quality, funding, testing, and qualification phases or reviews. If this is difficult, please consider our Certified Scrum Master and then Certified Scrum Product Owner seminars.
Input: Product Backlog that meets the Definition of Ready.
Output: One or more Product Backlog Items that meets the Definition of Done and any listed Acceptance Criteria.
SPRINT PLANNING: If a team is consistently succeeding in delivering completed missions and goals to their customer within the sprint length, the team may omit Sprint Planning. Sprint Planning is the shortest meeting possible for the people doing the work to communicate to the people who want the work done how much is likely to meet the quality bar by the end of the sprint, and for the people doing the work to create the initial plan of how the work will be approached.
Input: Product Backlog that meets the Definition of Ready.
Output: A sprint backlog that the Development Team and the Product Owner agree is likely to be completed, entirely meeting the Definition of Done and any listed Acceptance Criteria, within the agreed Sprint length.
DAILY SCRUM: If the people doing the work are already aware of what is in work, what is next, and what is blocked, and already aware of how to help each other in order to find the fastest responsible engineering practices and automation, the Daily Scrum may be omitted. The Daily Scrum is the shortest meeting possible to replan the day’s work for optimum output.
Input: status of what is done, what is in work, what is out for an external dependency, and any other updates to the Scrum Board.
Output: A plan for the day to make the most progress responsible in the healthiest, sustainable way.
SPRINT REVIEW: If psychological safety is high, and the development team is already receiving real-world user feedback within days of having completed a piece of work, and that feedback is being used to reprioritize which work to be done next and improve how that work item is attempted, the Sprint Review may be omitted. The Sprint Review is the shortest meeting practical for the people doing the work to explain how much of the Product Backlog they are statistically likely to bring to the Definition of Done within the next sprint, and create their initial plan to accomplish that.
Input: One or more Product Backlog Items that meets the Definition of Done and any listed Acceptance Criteria.
Output: Observation of a real or simulated user trying to use the Product Backlog Item produced. This step is frequently misunderstood, Product Backlog Items are used by the customer in Sprint Review, if the sprint did not produce something interesting for the customer the Sprint was too short for the team’s current level of automation and engineering practices.
SPRINT RETROSPECTIVE: If the people doing the work are consistently increasing speed without reducing quality, and psychological safety and well-being measures are adequate and increasing, the sprint retrospective may be omitted. The Sprint Retrospective is the shortest meeting practical to increase psychological safety and increase the speed and happiness of the team without deteriorating quality.
Input: Observation of the Sprint Review and the daily work of the last sprint.
Output: One kaizen, or continuous improvement initiative, to increase speed or happiness, committed to be completed within the next sprint and within the budget or capability of the Scrum Team.
3 OUTPUTS OR ARTIFACTS:
PRODUCT BACKLOG: If the Priority of what is highest value to work on is understood consistently by the people doing the work and the people who want the work done, and multi-tasking is minimal or non-existent, the Product Backlog may be omitted. The Product Backlog is a single ordered list of approximately sprint-sized projects, products, or services.
INPUT: Backlog Not Ready column, or list.
OUTPUT: The top of the product backlog is pulled into the Sprint Backlog by the Development Team during the Sprint Planning Event.
SPRINT BACKLOG: If the team is not having difficulty staying focused and not having issues with scope creep or other projects creating multitasking, a sprint backlog may not be needed as the purpose of the Sprint Backlog is being accomplished another way. A sprint backlog is a loose plan of how the Development Team believes they can bring the top Product Backlog Item to meet the Definition of Done and any listed Acceptance Criteria, within the sprint length, and have that success demonstrated within the Sprint Review.
POTENTIALLY SHIPPABLE PRODUCT INCREMENT: If the team hands their customer completed quality work at each sprint end, and the customer can leave with that work and use it, this output is being achieved. Note that an agile team that is not able to show the current product increment in process at any time has likely stalled in their progress, is confused, or otherwise has delivery risk. Also please note that a Product Increment almost always builds on previous Product Increments, and must be tested and evaluated as working with quality when integrated with previous increments and other likely real world products. This integration testing is part of the sprint and typically shown working as part of Sprint Review.
SCRUM ACCESSORIES:
NOT READY: A column or list just to the left of the Product Backlog where options for future work can be placed for consideration.
PRODUCT BACKLOG REFINEMENT: A meeting, or activity, where everyone helpful brings items in the Not Ready column to meet the Definition of Ready where it can be prioritized into the Product Backlog.
DEFINITION OF READY: A virtual poster, just to the left of the Not Ready column, stating what the Development Team agrees is a minimum amount of clarity and business alignment for a given Product Backlog Item to be low enough risk that they believe they have 80% or higher likelihood of completing that work within a sprint.
BLOCKED BOX: A place to put work that is waiting on an external dependency, such as another team or a vendor or a robotic process outside the team’s control.
DEFNITION OF DONE: The team’s commitment of the quality standard any work they put on their Wall of Done must meet.
WALL OF DONE: Columns for each sprint, scrolling back 4 sprints or more, showing what met the definition of done and was accepted by the team’s customer in each of the previous sprints.
TEAM WORKING AGREEMENT: A virtual poster, typically above the Sprint Backlog, stating how the Development Team members know who is on the team and their agreed behaviors. The list is typically less than 10 items to keep in memorable and useable.
SPRINT BURN DOWN CHART: A timed chart showing what met the Definition of Done and when during the sprint, with a forward trend line showing how much additional effort is likely to be completed before the sprint timebox ends. Burn Up charts are also perfectly recommended when we want to increase scope, such as attracting new projects and clients. Sprint Burn Down charts more quickly answer the question of when a particular scope will be completed, and are recommended when a specific scope is valuable if completed as soon as responsible.
RELEASE BURN DOWN CHART: A timed chart showing what met the Definition of Done and when during the current and any previous Sprints that worked on increments towards a larger product. For example, a modern car has thousands of parts. If the Development team is improving 20 parts per sprint on average with a Definition of Done of backwards compatibility, increased yield, faster production time, and lower cost, the Release Burn Down Chart will show a trend line to when all parts in production for the car are now meeting the new Definition of Done.
PERSONAS: Virtual Posters, typically just to the right of the Wall of Done, showing who are the likely or anticipated users, purchasers, maintainers, purchase influencers, internal stakeholders who fund or can influence the project, and regulatory compliance officials gating product release or use. Each persona displays a short name, a picture of the persona or their archetype, a short list of what they want from the product or service being built and what they don’t like or cause frustration related to the product or service being built. These Personas are used to assess value, create backlog to delight each persona to mitigate risk, group backlog to maximize persona engagement and support at the optimum timing, and eliminate scope that does not maximize the benefit to any of the personas.
RELATIVE SIZE ESTIMATION REFERENCES: Reference projects that the team is familiar with or ideally has recently completed allow the team to quickly and accurately (see our 6 year research study results examined in our Certified Scrum Master seminar) group future projects by effort and complexity relative to the references. Then by timing the completion time to the full Definition of Done and any listed Acceptance Criteria we can create a forward trend of when similar or even different sized projects are likely to be fully complete as well, and see if the team is speeding up or slowing down. The later point is often used to assess if additional automation or robotic support is increasing team speed. In practice, this is often a Small effort + complexity project and a Large effort + complexity project near the Not Ready column.
RELATIVE VALUE ESTIMATION REFERENCES: Reference projects are grouped by how much money they ultimately made or impact they ultimately created towards the company mission, plus risks reduced, plus new capabilities learned and practiced. This creates a value score. For the complete training in the methods of reliably obtaining the value score please see our Certified Scrum Product Owner seminar. Reference Projects labeled with value allow the people who want the work done to quickly assess rough value to the company, divide that by the relative level of effort supplied by the people who do the work, and then order the highest value, lowest effort work first after considering technical dependency. In practice, this is often a Small value and Large value project posted near the Not Ready column.
GROUP SCRUM BOARD: A large virtual board with a row for each team doing work and a column for each sprint going back to the first sprint each team was measured to have completed. Each cell of this grid shows the necessary KPI’s to run the entire business. In practice, these KPI’s are typically how much money or resource did each team consume in that sprint, how much money or resource did the output of that sprint make for the company (and if this is unknown, which is a tragically common problem, we typically have an immediate and severe problem with that team), how many points of effort that team completed in that sprint, any quality problems or quality score with their output that sprint, and what specifically was completed that sprint (the actual Product Backlog Items).
NEXT STEPS
Thank you for reading this fairly technical list of what Scrum actually is, how each piece works together, when to responsibly skip a piece of the 3-5-3 of Scrum, and which Scrum Accessories are recommended first and where they fit into the 3-5-3 of Scrum. Comments, corrections, compliments, and feedback are warmly welcomed. Now let’s make some worthwhile products really, really quickly as part of healthy and positive teams.
Joe Justice
Chair of the Agile Business Institute
Speaker at the Business Agility Conférence at Schoolab in march 2021 https://businessagilityconference.fr/paris/
Chair of the Agile Business Institute
Speaker at the Business Agility Conférence at Schoolab in march 2021 https://businessagilityconference.fr/paris/
