Scrum and Kanban

Kanban definitions

• « KANBAN » is a Japanese word meaning signboard :
  • the kanban method limits to work in progress and helps identify issues, minimizes waste and cost associated at each development.
• Kanban is a strategy for optimizing the flow of value through a process that uses a visual, pull-based system.
  • There may be various ways to define value, including consideration of the needs of the customer, the end-user, the organization, and the environment, for example.
  • Kanban comprises the following three practices working in tandem:
    • Defining and visualizing a workflow
    • Actively managing items in a workflow
    • Improving a workflow
  • In their implementation, these Kanban practices are collectively called a Kanban system.
  • Those who participate in the value delivery of a Kanban system are called Kanban system members.

Kanban purpose

• Central to the definition of Kanban is the concept of flow.
  • Flow
    • Flow is the movement of potential value through a system.
    • As most workflows exist to optimize value, the strategy of Kanban is to optimize value by optimizing flow.
  • Optimization
    • Optimization does not necessarily imply maximization.
      • Rather, value optimization means striving to find the right balance of effectiveness, efficiency, and predictability in how work gets done :
      • An effective workflow is one that delivers what customers want when they want it.
      • An efficient workflow allocates available economic resources as optimally as possible to deliver value.
      • A more predictable workflow means being able to accurately forecast value delivery within an acceptable degree of uncertainty.
    • The strategy of Kanban is to get members to ask the right questions sooner as part of a continuous improvement effort in pursuit of these goals.
    • Only by finding a sustainable balance among these three elements can value optimization be achieved.

Who can use Kanban ?

• Because Kanban can work with virtually any workflow, its application is not limited to any one industry or context.
• Professional knowledge workers, such as those in finance, marketing, healthcare, and software (to name a few), have benefited from Kanban practices.

Kanban Theory

• Kanban draws on established flow theory, including but not limited to : systems thinking, lean principles, queuing theory (batch size and queue size), variability, and quality control.
  • Continually improving a Kanban system over time based on these theories is one way that organizations can attempt to optimize the delivery of value.
  • The theory upon which Kanban is based is also shared by many existing value-oriented methodologies and frameworks.
  • Because of these similarities, Kanban can and should be used to augment those delivery techniques.

History of Kanban

• The present state of Kanban can trace its roots to the Toyota Production System (and its antecedents) and the work of people like Taiichi Ohno and W. Edwards Deming.
  • The collective set of practices for knowledge work that is now commonly referred to as Kanban mostly originated on a team at Corbis in 2006.
  • Those practices quickly spread to encompass a large and diverse international community that has continued to enhance and evolve the approach.

Kanban rules

• Managing business processes using Kanban can only be effective if it’s implemented properly.
  • An effective Kanban system is more than just sticking post-its on a board.
    • It is a mindset – a move towards productivity, organization, and eliminating waste through a steady flow of work. This is where the six rules of Kanban can come in handy.
  • A strong level of trust between leadership and staff is important to establish a steady flow of work.
    • But in order to achieve a high level of trust within the organization, expectations must be set.
    • We need a guide so everyone in the team knows how to do their work properly.
    • The six rules of Kanban will guide teams towards a successful and effective Kanban system implementation.
  • If you are serious in your Kanban practice, you need to ensure that these six rules are consistently followed in every business process you operate
• The Six Rules of Kanban
  • Never Pass Defective Products
  • Take Only What’s Needed
  • Produce the Exact Quantity Required
  • Level the Production
  • Fine-tune the Production or Process Optimization
  • Stabilize and Rationalize the Process
• Never Pass Defective Products
  • Upstream processes shouldn’t pass products that do not meet the standards and level of quality expected.
    • Defective products should be removed from the production line and be dealt with outside of it.
    • This ensures that only quality products go to your customers, lessens waste, and decreases customer complaints.
  • Policies help ensure that the desired level of quality is maintained at every step.
    • This is fairly straightforward for tangible goods production.
    • But the same applies to knowledge work.
  • For example, in software development, applications go through rigorous quality assurance testing before they’re released.
    • There can be Functional Testing, Regression Testing, Integration Testing, Performance Testing, and stress testing to name a few.
    • If the team agrees that all features and enhancements need to pass these levels of testing, then that’s the only time they can release them to market.
• Take Only What’s Needed
  • A successful Kanban implementation requires that downstream processes only pull what they need.
    • This prevents overproduction, lowers costs, and makes operations more reflective of the demands of the market.
  • Applying this rule as one of the six rules of Kanban is fairly straightforward for manufacturing processes.
    • For knowledge work, we can see this as only working on customer requests or orders when needed.
    • This also means following the priority in your backlog.
• Produce the Exact Quantity Required
  • Rule #3 of the six rules of Kanban works hand-in-hand with rule #2.
    • Taking only what you need would lead to only producing the exact quantity of products that are required.
      • If you overproduce, what are you going to do with that excess inventory?
        • You’re stocking up on more costs.
        • These include opportunity costs from the resources and money spent to build the item, storage costs, and transportation costs.
        • You also run the risk of having the product deteriorate or become obsolete.
  • How does this apply to knowledge work?
    • Having a Minimum Viable Product (MVP) mindset helps in this area.
    • If a customer wants to have the facility to download a report from your app, you don’t need to throw in a print feature as well.
    • Focus on the minimum requirements.
      • You can build on the product as the market demands or as your product direction leads you to it.
• Level the Production
  • In order to achieve a steady flow of work, all units within the Kanban system should only produce the number of items based on the capacity of its limiting contributor.
    • Illustrating this in the manufacturing setting, machine A can produce 500 units but machine B, its subsequent process, can only process 300 units at a time.
    • If we let machine A produce 500, a bottleneck will be experienced in machine B.
    • To solve this and let work flow smoothly, we must limit machine A’s production to 300.
    • You can explore Heijunka, another Lean concept, to see how you can level your production activities.
  • In knowledge work, we can see leveling by measuring the capacity of every step in your Kanban.
    • When you spot a bottleneck, you can alleviate the burden by augmenting your resources or setting your work-in-progress limit based on your limiting contributor.
• Fine-tune the Production or Process Optimization
  • Once the team has initialized its Kanban implementation, the next aim should be to utilize their Kanban system to surface pain points and improvement opportunities.
    • This would require a closer look at how work is flowing and measuring their performance.
  • Kanban metrics such as cycle time and lead time, and throughput will help teams get a quantitative and objective assessment of their work.
    • A Cumulative Flow Diagram (CFD) will help teams spot bottlenecks.
      • Online Kanban tools, such as Kanban Zone, have these metrics and reports built-in.
    • Teams must use the tools available for them to make informed decisions on how to optimize their process.
      • They must look for activities that produce waste.
      • This can be in the form of delays, defects, rework, and unnecessary handoffs to name a few.
      • Regular team retrospectives where teams discuss their experiences, pain points, and improvement suggestions and then formulate solutions to address them are key to fine-tuning production.
  • As inefficiencies decrease, work-in-progress items also decrease because the process is leaner.
• Stabilize and Rationalize the Process
  • When you ensure quality, level production, and optimize your process, your process gains stability.
    • A stable process enables standardization.
    • You should document your process so that there is a common shared understanding of how your team should operate.
    • Any deviations to the process standards should be managed by policies.
  • Having your standards explicit provides a strong foundation for your team to operate with predictability and consistency.
    • Your policies and standards can evolve through time as you continue to fine-tune your process.
    • Have regular team reviews to update your process and make your Kanban system more robust.
• When teams adhere to these six rules, they are more empowered to harness the benefits of Kanban.
  • The power of Kanban lies in the quality of its implementation.
  • When you take the six rules of Kanban to heart, you reduce waste, optimize your resources, become more cost-efficient, and maximize your productivity.

KANBAN practices

• VISUALIZE THE WORKFLOW
• LIMIT WIP :
  • keeping the amount of work in progress low increases the visibility on issues & facilitates continuous improvement.
• MANAGE FLOW :
  • tracking the flow and associated issues & changes can be measured for effectiveness.
• MAKE PROCESS POLICIES EXPLICIT :
  • clearly explain how this work and how to escalate issues.
• IMPROVE COLLABORATIVELY :
  • through scientific measurement and experimentation the team should collectively own and improve the processes it uses.

Scrum with Kanban purpose

• The flow-based perspective of Kanban can enhance and complement the Scrum framework and its implementation.
  • Teams can add complementary Kanban practices whether they are just starting to use the Scrum framework or have been using it all along.
  • Professional product development practitioners can benefit from the application of Kanban together with Scrum.

Kanban with Scrum Theory

• Flow and Empiricism
  • Central to the definition of Kanban is the concept of flow.
    • Flow is the movement of value throughout the product development system.
    • Kanban optimizes flow by improving the overall efficiency, effectiveness, and predictability of a process.
    • Optimizing flow in a Scrum context requires defining what flow means in Scrum.
  • Scrum is founded on empirical process control theory, or empiricism.
    • Key to empirical process control is the frequency of the Transparency, Inspection and Adaptation cycle
      • which we can also describe as the Cycle Time through the feedback loop.
    • When Kanban practices are applied to Scrum, they provide a focus on improving the flow through the feedback loop; optimizing transparency and the frequency of inspection and adaptation for both the product and the process.

Kanban Metrics

• The application of Kanban requires the collection and analysis of a minimum set of flow measures (or metrics).
• They are a reflection of the Kanban system’s current health and performance and will help inform decisions about how value gets delivered.
• The four basic metrics of flow that Scrum Teams using Kanban need to track are as follows :
  • Work in Progress (WIP)
  • Cycle Time
  • Work Item Age
  • Throughput

Work in Progress (WIP)

• The number of work items started but not finished.
  • The team can use the WIP metric to provide transparency about their progress towards reducing their WIP and improving their flow.
  • Note that there is a difference between the WIP metric and the policies a Scrum Team uses to limit WIP.

Cycle Time

• Cycle time is the amount of elapsed time between when a work item starts and when a work item finishes.

Work Item Age

• Work Item age is the amount of time between when a work item started and the current time.
  • This applies only to items that are still in progress.

Throughput

• Throughput is the number of work items finished per unit of time.
  • Note the measurement of throughput is the exact count of work items.

Kanban practice

• Scrum Teams can achieve flow optimization by using the following practices :
  • Defining and Visualizing the Workflow
  • Actively Managing Work Items in a Workflow and Limiting Work in Progress (WIP)
  • Improving the Workflow
  • Inspecting and adapting the team’s Definition of Workflow (DoW)

Defining and Visualizing the Workflow

• Optimizing flow requires defining what flow means in a given context.
  • The explicit shared understanding of flow among Kanban system members within their context is called a Definition of Workflow (DoW).
  • DoW is a fundamental concept of Kanban.
    • All other elements of the Kanban guide depend heavily on how workflow is defined.
    • Definition of Workflow
  • The four Kanban practices are enabled by the Scrum Team’s Definition of Workflow (DoW).
    • This definition represents the Scrum Team members’ explicit understanding of what their policies are for following the Kanban practices.
    • This shared understanding improves transparency and enables self-management.
      • Note that the scope of the Definition of Workflow may span beyond the Sprint and the Sprint Backlog.
        • For instance, a Scrum Team’s Definition of Workflow may encompass flow inside and/or outside of the Sprint.
    • Creating and adapting the Definition of Workflow is the accountability of the relevant roles on the Scrum Team as described in the Scrum guide.
      • No one outside of the Scrum Team should tell the Scrum Team how to define their Workflow.
  • At minimum, members must create their DoW using all of the following elements :
    • A definition of the individual units of value that are moving through the workflow.
      • These units of value are referred to as work items (or items).
    • A definition for when work items are started and finished within the workflow.
      • Your workflow may have more than one started or finished points depending on the work item.
    • One or more defined states that the work items flow through from started to finished.
      • Any work items between a started point and a finished point are considered work in progress (WIP).
    • A definition of how WIP will be controlled from started to finished.
    • Explicit policies about how work items can flow through each state from started to finished.
    • A service level expectation (SLE), which is a forecast of how long it should take a work item to flow from started to finished.
  • Kanban system members often require additional DoW elements such as values, principles, and working agreements depending on the team’s circumstances.
    • The options vary, and there are resources beyond this guide that can help with deciding which ones to incorporate.
• Visualization of the workflow
  • The visualization of the DoW is called a Kanban Board.
    • Making at least the minimum elements of DoW transparent on the Kanban Board is essential to processing knowledge that informs optimal workflow operation and facilitates continuous process improvement.
    • There are no specific guidelines for how a visualization should look as long as it encompasses the shared understanding of how value gets delivered.
      • Consideration should be given to all aspects of the DoW (e.g., work items, policies) along with any other context-specific factors that may affect how the process operates.
      • Kanban system members are limited only by their imagination regarding how they make flow transparent.
  • Visualization using the Kanban Board is the way the Scrum Team makes its Workflow transparent.
    • The board’s configuration should prompt the right conversations at the right time and proactively suggest opportunities for improvement.
    • Visualization should include the following :
      • Defined points at which the Scrum Team considers work to have started and to have finished.
      • A definition of the work items
        • the individual units of value (stakeholder value, knowledge value, process improvement value) that are flowing through the Scrum Team‘s system (most likely Product Backlog items (PBIs)).
        • A definition of the workflow states that the work items flow through from start to finish (of which there must be at least one active state).
      • Explicit policies about how work flows through each state (which may include items from a Scrum Team’s Definition of Done and pull policies between stages).
      • Policies for limiting Work in Progress (WIP).

Actively Managing Items in a Workflow and limiting Work In Progress (WIP)

• Active management of items in a workflow can take several forms, including but not limited to the following :
  • Controlling WIP.
  • Avoiding work items piling up in any part of the workflow.
  • Ensuring work items do not age unnecessarily, using the SLE as a reference.
  • Unblocking blocked work.
• Active Management of Work Items in Progress
  • Limiting WIP is necessary to achieve flow, but it alone is not sufficient.
  • The third practice to establish flow is the active management of work items in progress.
  • Within the Sprint, this management by the Scrum Team can take several forms.
  • Different forms including but not limited to the following :
    • Making sure that work items are only pulled into the Workflow at about the same rate that they leave the Workflow.
    • Ensuring work items aren’t left to age unnecessarily.
    • Responding quickly to blocked or queued work items as well those that are exceeding the team’s expected Cycle Time levels (See Service Level Expectation – SLE).
• A common practice is for Kanban system members to review the active management of items regularly.
  • Although some may choose a daily meeting, there is no requirement to formalize the review or meet at a regular cadence so long as active management takes place.
• Controlling Work In Progress
  • Kanban system members must explicitly control the number of work items in a workflow from start to finish.
    • That control is usually represented as numbers or slots/tokens on a Kanban board that are called WIP limits.
    • A WIP limit can include (but is not limited to) work items in a single column, several grouped columns/lanes/areas, or a whole board.
  • A side effect of controlling WIP is that it creates a pull system.
    • It is called a pull system because Kanban system members start work on an item ( pulls or selects) only when there is a clear signal that there is capacity to do so.
    • When WIP drops below the limit in the DoW, that is a signal to select new work.
    • Members should refrain from pulling/selecting more than the number of work items into a given part of the workflow as defined by the WIP Limit.
    • In rare cases, system members may agree to pull additional work items beyond the WIP Limit, but it should not be routine.
  • Controlling WIP not only helps workflow but often also improves the Kanban system members’ collective focus, commitment, and collaboration.
    • Any acceptable exceptions to controlling WIP should be made explicit as part of the DoW.
  • Service Level Expectation
    • The SLE is a forecast of how long it should take a single work item to flow from started to finished.
    • The SLE itself has two parts: a period of elapsed time and a probability associated with that period (e.g., “85% of work items will be finished in eight days or less”).
    • The SLE should be based on historical cycle time, and once calculated, should be visualized on the Kanban board.
    • If historical cycle time data does not exist, a best guess will do until there is enough historical data for a proper SLE calculation.
• Limiting Work in Progress (WIP)
  • Work in Progress (WIP) refers to the work items the Scrum Team has started but has not yet finished.
    • Scrum Teams using Kanban must explicitly limit the number of these work items in progress.
    • A Scrum Team can explicitly limit WIP however they see fit but should stick to that limit once established.
    • The primary effect of limiting WIP is that it creates a pull system.
      • It is called a pull system because the team starts work (i.e. pulls) on an item only when it is clear that it has the capacity to do so.
      • When the WIP drops below the defined limit, that is the signal to start new work.
      • Note this is different from a push system, which demands that work starts on an item whenever it is requested.
  • Limiting WIP helps flow and improves the Scrum Team’s self-management, focus, commitment, and collaboration.

Improving the Workflow

• Having made the DoW explicit, the Kanban system members’ responsibility is to continuously improve their workflow to achieve a better balance of effectiveness, efficiency, and predictability.
  • The information they gain from visualization and other Kanban measures guide what tweaks to the DoW may be most beneficial.
• It is common practice to review the DoW from time to time to discuss and implement any changes needed.
  • There is no requirement, however, to wait for a formal meeting at a regular cadence to make these changes.
  • Kanban system members can and should make just-in-time alterations as the context dictates.
  • There is also nothing that prescribes improvements to workflow to be small and incremental.
  • If visualization and the Kanban measures indicate that a big change is needed, that is what the members should implement.

Inspecting and Adapting the Definition of Workflow

• The Scrum Team uses the existing Scrum events to inspect and adapt its Definition of Workflow, thereby helping to improve empiricism and optimizing the value the Scrum Team delivers.
• The following are aspects of the Definition of Workflow the Scrum Team might adopt :
  • Visualization policies
    • for example, Workflow states – either changing the actual Workflow or bringing more transparency to an area in which the team wants to inspect and adapt.
  • How-we-work policies
    • these can directly address an impediment.
      • For example, adjusting WIP limits and SLEs or changing the batch size (how often items are pulled between states) can have a dramatic impact.

Kanban measuring practice

• For these mandatory four flow metrics, the terms started and finished refer to how the Kanban system members have defined those terms in the Definition of Workflow (DoW).
  • Provided that the members use these metrics as described in the Kanban guide, members can refer to any of these measures using any other names as they choose.
  • In and of themselves, these metrics are meaningless unless they can inform one or more of the three Kanban practices.
    • Therefore, visualizing these metrics using charts is recommended.
    • It does not matter what kind of charts are used as long as they enable a shared understanding of the Kanban system’s current health and performance.
  • The flow measures listed in this guide represent only the minimum required for the operation of a Kanban system.
    • Kanban system members may and often should use additional context-specific measures that assist data-informed decisions.

Flow-Based Events

• Kanban in a Scrum context does not require any additional events to those outlined in the Scrum guide.
  • However, using a flow-based perspective and metrics in Scrum’s events strengthens Scrum’s empirical approach.
• The Sprint
  • The Kanban complementary practices don’t invalidate the need for Scrum’s Sprint.
    • The Sprint and its events provide opportunities for inspection and adaptation of both product and process.
    • It’s a common misconception that teams can only deliver value once per Sprint.
    • In fact, they must deliver value at least once per Sprint.
  • Scrum Teams using Scrum with Kanban use the Sprint and its events as a feedback improvement loop by collaboratively inspecting and adapting their Definition of Workflow and flow metrics.
  • Kanban practices can help Scrum Teams improve flow and create an environment where decisions are made just-in-time throughout the Sprint based on inspection and adaptation.
  • In this environment, Scrum Teams rely on the Sprint Goal and close collaboration within the Scrum Team to optimize the value delivered in the Sprint
• Sprint Planning
  • A flow-based Sprint Planning meeting uses flow metrics as an aid for developing the Sprint Backlog.
  • Reviewing historical throughput can help a Scrum Team understand their capacity for the next Sprint.
• Daily Scrum meeting
  • A flow-based Daily Scrum focuses the Developers on doing everything they can to maintain consistent flow.
  • While the goal of the Daily Scrum remains the same as outlined in the Scrum Guide, the meeting itself takes place around the Kanban Board and focuses on where flow is lacking and on what actions the Developers can take to get it back.
  • Additional things to consider during a flow-based Daily Scrum include the following :
    • What work items are blocked and what can be done to get them unblocked?
    • What work is flowing slower than expected?
    • What is the Work Item Age of each item in progress?
    • What work items have violated or are about to violate their SLE and what can the Scrum Team do to get that work completed?
    • Are there any factors not represented on the board that may impact our ability to complete work today?
    • Have we learned anything new that might change what the Scrum Team has planned to work on next?
    • Have we broken our WIP limit?
    • What can we do to ensure we can complete the work in progress?
• Sprint Review
  • The Scrum Guide provides an outline of the Sprint Review.
  • Inspecting Kanban flow metrics as part of the review can create opportunities for new conversations about monitoring progress towards the Product Goal.
  • Reviewing Throughput can provide additional information when the Product Owner discusses likely delivery dates.
• Sprint Retrospective
  • A flow-based Sprint Retrospective adds the inspection of flow metrics and analytics to help determine what improvements the Scrum Team can make to its processes.
  • The Scrum Team using Kanban also inspects and adapts the Definition of Workflow to optimize the flow in the next Sprint.
    • Using a cumulative flow diagram to visualize a Scrum Team’s WIP, approximate average Cycle Time and average Throughput can be valuable.
  • In addition to the Sprint Retrospective, the Scrum Team should consider taking advantage of process inspection and adaptation opportunities as they emerge throughout the Sprint.
  • Similarly, changes to a Scrum Team’s Definition of Workflow may happen at any time.
    • Because these changes will have a material impact on how the Scrum Team performs, changes made during the regular cadence provided by the Sprint Retrospective event will reduce complexity and improve focus, commitment and transparency.

Increment

• Scrum requires the Scrum Team to create (at minimum) a valuable, useful Increment every Sprint.
  • Scrum’s empiricism encourages the creation of multiple valuable increments during the Sprint to enable fast inspect and adapt feedback loops.
  • Kanban helps manage the flow of these feedback loops more explicitly and allows the Scrum Team to identify bottlenecks, constraints, and impediments to enable this faster, more continuous delivery of value.

Little law

• See scrumandkanban.co.uk/littles-law/
• What is Little’s Law?
  • If you have a stable system (e.g. one-in-one-out), then the average number of customers you have within that system is equal to the average rate of customer arrivals multiplied by the average time a customer spends in the system.
  • That was the law proposed by John Little in the mid-1900s.
  • This is commonly expressed as L = λW (where “L” is the average number of customers, “λ” is average arrival rate and “W” is the average time in the system).
  • Popular in queueing theory, the law proves that when you increase the number of customers in the system, and keep the arrival rate constant, the average time in the system increases.
    • In short, increasing the number of customers means that it takes longer for each one to be served.
    • Maybe you remember from school, that you can rework L = λW to show that λ = L / W and W = L / λ
• Why do we care?
  • We slightly redefine the terms as follows :
    • average number of customers becomes average items of work in progress (WIP)
    • average arrival rate becomes average delivery rate (DR)
      • we can change this because arrival and departure time will be the same in a stable one-in-one-out system
    • average time in the system, the average time it takes to go from start to finish, is known to us as lead time (LT)
  • For us, Little’s Law tells us that WIP = DR x LT (which can also be expressed as DR = WIP / LT and LT = WIP / DR).
    • We can then use Little’s Law to prove that increasing the average amount of work in progress (WIP) has the effect of increasing the average time it takes for each work item to be completed (Lead Time).
      • For example , we have an average of 6 work items in progress, an average delivery rate of 2 items per day, and an average lead time of 3 days.
        • WIP = DR x LT, 6 = 2 x 3
        • If you remember your childhood lessons on refactoring algebra, this can also be expressed as:
          • LT = WIP / DR
          • LT = 3 (6 / 2)
      • Using this refactored equation, we can see what happens to lead time if we increase WIP to 12 :
        • LT = WIP / DR
        • LT = 12 / 2
        • LT = 6
        • Lead time increases from 3 days to 6 days.
        • But doesn’t this also prove that increasing WIP can increase Delivery Rate?
          • If we take our initial example, increase WIP to 12 but keep lead time as 3 days, then we get:
            • DR = WIP / LT
            • DR = 12 / 3
            • DR = 4
• By increasing WIP, we have also increased delivery rate!
  • Isn’t this a good thing?
  • Although that might be true from an algebric perspective, it’s not what usually happens.
    • If I doubled your workload, you’re unlikely to suddenly become twice as productive and complete it in the same time; you will just take twice as long to complete twice as much work, delivering at about the same rate as before.
    • So, in short, Little’s Law tells us:
      • if you increase WIP, without finding a way of increasing delivery rate, then your lead time will increase.
      • Conversely, it tells us that decreasing WIP may reduce lead time.

Caution

• Kanban’s practices and measures are immutable.
  • Although implementing only parts of Kanban is possible, the result is not Kanban.
• One can and likely should add other principles, methodologies, and techniques to the Kanban system, but the minimum set of practices, measures, and the spirit of optimizing value must be preserved.
• Scrum is not a process or technique.
  • Scrum is a framework within which people can address complex adaptive problems while productively and creatively delivering products of the highest possible value.
  • As the Scrum Guide points out, it functions well as a container for other techniques, methodologies, and practices.

See PMI-ACP exam,

Updated : 25/10/2021