Home > Articles > Software Development & Management > Agile

  • Print
  • + Share This
This chapter is from the book

The Kickstart Event

As with any initiative, adoption of Scrumban should start with some type of “formal” event. Though simpler to launch than a direct transformation to Scrum, some elements of “education” and setting expectations are still necessary to ensure a smooth start. All team members should be physically present for any kick-off meeting. This is obviously more of a challenge with distributed teams, so some consideration must be given to communications and visualization. The topics that the agenda for a good kick-off event should, at a minimum, address are covered in the following sections.

Introductory Remarks

The kick-off event is an opportunity to set the stage for what follows. Remarks should reinforce at least two key concepts.

First, you want to underscore that this effort is solely about introducing and employing Scrumban in the context of your current ways of working, and represents little to no change in existing work roles or responsibilities. It’s important to address this point up front to minimize the potential barriers to effective learning caused by fear or resistance to change.

Second, you should reinforce the fact that this event has just one achievable outcome—each team walking away with a clear visualization of how it works. As with threatened change, epic objectives create unnecessary psychological barriers. Communicating an achievable outcome up front will help engage participants early on and make the kickstart process considerably more meaningful. We define our “definition of done” for this step as follows:

  • Each team member has a clear understanding of his or her team’s purpose.
  • Each team has created a visual representation of its ongoing work and current workflow.
  • All team members agree on their most important and relevant work policies.

Current Concerns

Service orientation lies at the core of the Scrumban framework, so it’s critical for teams to begin with a clear identification of their stakeholders and any dissatisfaction they might have. Getting stakeholders to work with you, instead of against you, is one of your greatest tools for achieving continuous improvement.

Though adjustments should always be made based on the context of your environment, Klaus Leopold recently articulated one approach for visualizing stakeholder relationships that seems particularly informative and useful for introducing Scrumban to an organization.6 Among the suggestions he offers are the following:

  • Visualizing the power and influence of each stakeholder using different size cards.
  • Visualizing the degree to which stakeholders support your initiative through a spatial reference point: The closer to the point they’re positioned, the stronger their level of support. Although Leopold’s article specifically speaks to stakeholder relationships relative to undertaking a change initiative in general, there’s no reason this approach can’t be undertaken for any initiative.
  • Visualizing the frequency of the relationships among stakeholders with different style lines (e.g., dotted for infrequent or tenuous connections, other styles for different grades).
  • Visualizing the quality of the relationship with special symbols (e.g., friendly or adversarial, healthy and strong or tenuous and weak).

Why engage in this evaluation of stakeholders? Because you need to understand your stakeholders’ sources of dissatisfaction, and find the most effective ways to work with them toward resolving those issues. In fact, teams should change their work policies and work visualizations only if doing so will help resolve areas of dissatisfaction.

Visualizing the dynamics associated with key relationships also creates a clear view of who holds the most power, the current state of each relationship, and the steps that must be taken to move closer to a solution. It helps prioritize an approach to resolving dissatisfaction.

If you’re looking to apply an even greater level of calibration to the process, this arena is ripe for applying a model like the Cynefin framework to provide information on how best to manage a given relationship.

In most circumstances, it is appropriate to facilitate discussions around current issues. Simply invite members to identify the top three to five issues that represent irritants or impediments to their work. Any issues that relate to how work is done or how the team interacts with other groups can be set aside for possible discussion, as these represent way-of-working or policy matters the team will be addressing during the kickstart. Any others should be tabled, as they don’t relate to issues relevant to the workshop.

Defining Purpose and Success Criteria

Teams and organizations that lack a common purpose typically cannot achieve or sustain high levels of performance. Any exercise that moves them toward a common understanding of purpose and criteria for success is all that matters. I like to have teams answer the question, “Why does our team exist?”

You should skip this step only when you’re sure everyone agrees they’re on a common journey to pursue incremental change toward working more effectively.

Identifying How Work Is Done

The goal for this segment is to have teams gain a realistic understanding of their current situation—in other words, how they actually perform work versus how they think they perform work. We get to this point by introducing a systems perspective—by asking the team to visualize itself as a closed system having several basic components (Figure 5.8). This exercise may be the first time many teams acquire a realistic sense of the complexity of how work flows in and out of their domain, plus the full scope of what they’re responsible for producing on an ongoing basis.

Figure 5.8

Figure 5.8 Visualizing a closed system.

The team’s articulation of upstream demand represents which work they’re asked to perform, who makes those demands (internal customers, external customers, or a combination of both), how those demands are communicated, and what their relative frequency and quantity are. These understandings are used to categorize work types later in the workshop.

Defining the downstream end reinforces the notion of recipients as consumers or partners in a process, thereby reinforcing Kanban’s concept of knowledge work as service delivery. These initial definitions of system boundaries clarify the scope of the team’s responsibility—where their work begins and ends.

Articulating how the team performs its work should command most of the team’s attention. Teams should be guided to creating a simple, high-level visualization of the stages that each type of work must pass through before completion; this will be the foundation upon which their working board is built. Simple and abstract is the key—no more than 2–3 different kinds of workflows and no more than 7–10 stages in each.

Focusing on Work Types

A good kickstart process will incorporate activities that ensure team members acquire a common understanding of work types and their significance. It may be relevant to your organizational context to have teams identify and manage their work using predefined types, but in any case it’s important for the team to understand the nature of the demands placed upon them. Naturally, this is an ongoing process. Common modes of approaching this include assessing which work types meet the following criteria:

  • Have the most value for their customers or partners
  • Are demanded the most and the least (in terms of quantity)
  • Are usually more urgent than others
  • Are best aligned with the team’s purpose (the kind of work the team should do to a greater extent)
  • Are least aligned with the team’s purpose (the kind of work the team should do to a lesser extent)

It may be relevant to your organizational context to have teams identify and manage their work using predefined types. Nevertheless, regardless of how you elect to proceed, it’s ultimately most important that they understand the nature of the demands being placed upon them. Naturally, this is an ongoing process. Common categorizations include the following:

  • By source (e.g., retail banking, product X, maintenance items)
  • By size (e.g., in terms of effort)
  • By outcome (e.g., production release, analysis report)
  • By type of flow (e.g., development, maintenance, analysis)
  • By risk profile (e.g., standard work, urgent work, regulatory compliance)
  • By relevance (how closely the work is aligned with team purpose)

Whatever scheme you choose, categorization provides a frame of reference against which an appropriate balance of work in progress can be created and managed.

Basic Management

It’s one thing to have teams begin visualizing how they work; it’s another thing to provide them with a framework for using these visualizations to discover better ways of managing it. I recommend using the GetScrumban game (Figure 5.9) to introduce teams to the basic principles behind managing their workflow. (Full disclosure: I designed this game.) It’s usually employed in tandem with other “classroom” exercises to illustrate and emphasize key principles and practices.

Figure 5.9

Figure 5.9 The GetScrumban game lets players experience the typical evolution of Scrum teams after introducing the Scrumban framework into their way of working.

Source: GetScrumban.com.

The GetScrumban game simulates how a software development team that employs Scrum as its chosen framework can use Scrumban’s core principles and practices to amplify its current capabilities, overcome common challenges, or forge new paths to improved agility. The game allows players to experiment with and experience the impact of these principles and practices:

  • Expanded visualizations

    • Value streams
    • Types of work
    • Risk profiles
  • Pulling work versus assigning work
  • Evolutionary adjustments versus radical change
  • Cost of delay versus subjective prioritization
  • Distinct classes of service versus a single workflow
  • Continuous flow versus time-boxed iterations
  • Value of options

Whether you use an interactive tool like GetScrumban or employ some other mode of instruction, your teams should walk away with an understanding of the following:

  • Concepts Already Familiar to Scrum Teams

    • Work items/cards (user stories): These are typically visualized on physical boards in the form of a sticky.
    • Work size estimate (story points): As most Scrum teams already engage in some form of estimation, the concept of estimating (and the notion of breaking larger stories down into more manageable sizes) should be very familiar.
    • Definition of done: A short checklist of standards that must be present for a work item to move from one column to another.
    • Daily stand-ups: Scrumban stand-ups tend to eliminate declarations of status (what each team member completed, what the team member is committing to complete, and the identification of impediments) because all of that information is already visualized on the board. Instead, stand-ups evolve to focus on how well work is flowing and which actions the team can take to improve overall flow and delivery of value.
  • New Concepts

    • Work type: Often represented by the color of a work card; reflects the mix of work in progress. Visualizing and actively managing the mix of work (i.e., standard user story, bug fix, maintenance item, estimations) is usually a novel concept for Scrum teams.
    • Workflow: Columns on a work board represent the value-adding stages work passes through to completion. These usually start with “Ready” and conclude with “Done,” “Ready to Deploy,” or some similar terminology. Scrum teams often welcome this change because story progress and individual contributions toward it are made more visible.
    • Pull: Though some Scrum teams may be familiar with pull-based systems, many others are new to this mechanism. Pull mechanisms avoid clogging the system with too much work. Rather than work being “pushed” onto a team by those with a demand, the team selects work to pull into their work stream when they have the capacity to handle it.
    • Ready for pull: These “holding” areas are visualized as columns within a column. Typically used when a handover occurs (such as from a development phase to a test phase), they help manage bottlenecks.
    • Definition of ready: A short checklist at the bottom of a “Ready” column that visualizes the relationship a team has with those requesting work. The definition should specify the information or resources a team needs to effectively begin working on an item. Though many Scrum teams may employ definitions of ready in their work, they are rarely explicitly defined and visualized within a working framework.
    • Blockers: Flags that indicate when work on an item is suspended because of dependencies on others. Blockers are usually visualized as an additional sticky or magnet (pink or red) on a work item. The purpose is to call attention to such items so the team attends to removing the impediment. Some Scrum teams may already visualize blockers on their task boards.
    • Classes of service: Different “swim lanes” used to call out different risk profiles associated with given work items. We can choose to visualize separate classes of service to reflect and manage risk better (e.g., helping to ensure higher risk profiles attract more attention from the team than lower risk profiles. Similarly, you may want to help the team recognize it’s okay to take longer to complete lower-risk items.
    • Explicit WIP limits: Teams should limit the amount of work in progress at any given time. We can do this by establishing explicit WIP limits across the board, within each column (preferred), within each swim lane/class of service, by work type, by team member, or any combination. Limiting WIP improves flow efficiency (by reducing or eliminating the cost of context-switching, among other things).

Common Language (Optional)

If you’re looking to align Scrumban practices across a large number of teams, it’s usually beneficial to establish a “common language” around common concepts. It’s possible to borrow some terms from Scrum (for example, teams might all carry a “backlog” or items that are ready to be worked on). Similarly, it may make sense for teams working on different aspects of the same program to use the same visualization scheme and share common policies.

Visualization Policies

One of Scrumban’s core practices is to ensure that all work policies are explicit. We do so to ensure that everyone is on the same page, and that the work policies can be easily remembered and shared with others. Common practices include the following:

  • Work items: Most practices will be natural carry-overs from Scrum:

    • Due date (if any).
    • External reference (e.g., from a management/tracking tool).
    • Size of work (e.g., story points or person-hour estimates).
    • Start date (important to track for measurement purposes).
    • End date (date work was fully completed—some metrics can be impacted by how you measure this, but any agreed-upon policy is sufficient when starting out).
  • Workflow: The basic elements should already be incorporated in the systems diagram the team developed earlier. Some columns may be adjusted and rows added, however, as the team’s understanding develops.

    • Pull Criteria: Scrum practitioners familiar with Definition of Done can optionally break it up into more granular lightweight “Pull criteria” visualized as a combination of mandatory and optional conditions before which a pull can be made.
  • What not to visualize: Cluttering up your visualization with unnecessary items defeats the objective of bringing greater clarity and understanding to how you work. Although teams should capture as much of their work as possible, there can be legitimate omissions, as in the following examples:

    • Administrative activities (such as meetings unrelated to ongoing work). However, there may be great value to capturing how much time meetings are taking away from actual work, or whether certain resources are more encumbered than others.
    • Short, ad hoc work (5- to 10-minute requests or incidents). As with administrative activities, there can be value in capturing these items. Measuring the number of such work items in the course of a day or week could reveal a significant and ongoing demand that would otherwise fly beneath the radar.

Frequency of Synchronization

Daily meetings are as much a ceremony with Scrumban as they are with Scrum. Unlike in Scrum, however, teams can move beyond sharing status and making commitments to collaborating on impediments to workflow and recognizing opportunities for improvement. This requires the team’s visual board to be in sync with reality. Some development teams may be able to get by with once-a-day synchronization, whereas others will need real-time updates. Decisions made in this context can impact tool choices and other related factors.

Create a Working Board

The kickstart session is an ideal time to assist teams with setting up their working boards. The sooner a team starts to see and work with actual items, the more relevant the process becomes. This effort typically involves the following steps:

  • Drawing the workflow: Creating columns that represent the value stream of the team’s work process.
  • Creating the board: I recommend that the teams create the board together, whether it’s an electronic tool or physical board. This accelerates team learning and ownership.
  • Ticket design: The information to incorporate on a work ticket will vary from team to team. We discuss these considerations in more detail in Chapter 7.
  • Adding current work (self-explanatory).

This is also an ideal time for teams to establish their definition of ready and definition of done for work items and lanes. Ready definitions can be easy to neglect, but they help avoid potential blockages once work begins. Teams might also discuss prioritization, but in a Scrum context this issue should have been already addressed by product owners.

Way of Working Policies

It’s critical that all team members agree how work will be handled in their visual boards so that it is done in a consistent manner. Areas to address include the following:

  • Which individual(s) will be responsible for managing the ready buffer (placing new work items in the buffer and prioritizing them for the team to address as capacity allows). This topic is not relevant for teams that continue to use time-boxed sprints.
  • When and how the ready buffer will be replenished. For teams that continue practicing Scrum, this usually coincides with the sprint planning process. In complex environments, developing policies could become quite involved. The immediate objective is simply to have a workable starting point.
  • Which individual(s) will be responsible for managing completed work (especially important when work is to be forwarded to downstream partners).
  • How ad hoc work or requests from outside normal channels should be managed. Consideration must be given to the needs of the system making the request.
  • When work should be pulled from the ready buffer (typically whenever a team member has capacity and can’t contribute to any ongoing work). Consideration should be included for managing WIP limits and what should occur if exceptions are to be made.

Most of these considerations involve assessing risk (addressed further in Chapter 6). Having teams explicitly address risk as part of the kickstart process is the best way of ensuring more considered management as they mature. At a minimum, teams should be encouraged to explicitly articulate how work will be prioritized and which considerations are expected to be addressed as part of this process (i.e., is prioritization based exclusively on market/business risks, or should the decision incorporate an assessment of risks associated with the underlying technology, the complexity of the work, the team’s familiarity with the domain, and other factors).

Limiting WIP

Setting explicit limits on work in progress will be a new concept for Scrum teams, and the science behind this mandate can be counterintuitive. For teams already practicing Scrum, it may be beneficial to point out how the Sprint ceremony is an implicit WIP-limiting mechanic. The idea is not to dive into detail, but rather to provide enough of an overview so the team understands why limiting work in progress matters.

“Stop starting and start finishing” should become every team’s mantra. Pull mechanisms are one way to ensure new work items are started only when a team member has capacity to do the work, thereby enabling the team to eventually attain a stable WIP level that matches its total capacity. Explicit WIP limits are another strategy (but should really be reserved for more mature teams, as they require a more complete understanding and practice of many core concepts).

To help ensure system agility, it’s essential to maximize your options. The more tightly work is packed within a system, the less agile you become (tightly packed work reduces your available options to respond to changes in circumstances). Limiting WIP is one mechanism for maintaining a sufficient amount of slack to ensure a smoother flow through the system.

A commonly used approach when introducing teams to the concept of explicit WIP limits is to establish them based on available resources or some other factor that’s not associated with actual demand and capacity. As with most things, the best approach will be dictated by the team’s specific context.

As the team performs work, circumstances may call for violating WIP limits. These are learning opportunities, and should always trigger a discussion. Perhaps current limits are too low and should be raised. Or perhaps circumstances are such that the need constitutes a one-time exception. Regardless of the context, WIP limits represent an essential constraint that forces teams to improve their process and way of working.

Teams will confront some common challenges with regard to establishing and abiding by WIP limits (we address these in greater detail in Chapter 7). These include the following issues:

  • Variability: In the form of demand, the work, the risks, and numerous other factors.
  • Constraints: Constraints ultimately determine system capacity. In knowledge work, they tend to move around, making them difficult to identify and manage. This makes discovering and establishing the right WIP limits very challenging.
  • Human nature: People are funny. They often mask their true desires and intentions in less than obvious ways.

Planning and Feedback Loops

Scrum practitioners are already used to daily check-ins. Employing Scrumban, however, presents the opportunity to shift the meeting’s focus from status and commitment to more proactive planning. The kanban board already provides status information and should detail who is working on what. Impediments should also be visualized. Consequently, the focus of the team’s discussion can shift to a collaborative effort geared toward identifying potential impediments, dealing with requested exceptions to policies, and otherwise addressing discoveries about how work is being performed.

If your Scrum teams are made up of inexperienced practitioners, it’s possible they don’t know whether their existing stand-ups are even effective. If the teams to which you’re about to introduce Scrumban fall into this category, the kickstart is an opportunity to help them improve.

Jason Yip, a principal consultant at the firm Thoughtworks, has effectively summarized patterns to establish for a good stand-up (easily remembered using the mnemonic GIFTS):

  • Good start: Good stand-ups should be energizing, not demotivating.
  • Improvement: The primary purpose of the meeting is to support improvement, not to discuss status.7
  • Focus: Stay focused on the right things, which should be to move work through the system (rather than dwelling on pointless activities).
  • Team: Good stand-ups foster effective communication and collaboration. If people aren’t helping one another during stand-ups, something is awry.
  • Status: Stand-ups should communicate a basic sense of what’s going on. As previously noted, the actual conversations move away from this information in Scrumban (i.e., this information should be communicated through the kanban board).

Scrum’s time-boxed Sprint remains the main vehicle for coordinating the delivery of completed work and replenishing the team with new work. Over time, teams can opt to modify the process for replenishment and commitment to delivery (and even de-couple these cadences) to adopt approaches more focused on actual demand and capacity.

Sprint Reviews and Retrospectives are existing feedback loops within the Scrum framework that we tweak in some measure when practicing Scrumban. For example, whereas Sprint Reviews are focused on soliciting customer feedback on the delivery of completed product, in Scrumban we incorporate the concept of reviewing overall service delivery (borrowing from the Kanban Method’s Service Delivery and Risk Review cadences). Similarly, the Sprint Retrospective takes on more of the flavor of the Kanban Method’s Operations Review.

It is also important to mention the importance of conducting organizational level feedback loops, such as the Strategy Review cadence integrated within the Kanban Method.

Individual Flow (Optional)

Some of the concepts and techniques Scrumban employs to give teams greater control over their collective focus and workflow are not obvious and are sometimes counterintuitive. Devoting a portion of your kickstart program to techniques for managing personal workflow is one way to enhance appreciation of their effectiveness. Topics of particular relevance include the following:

  • Managing energy and not time (introduced via the Pomodoro technique, for example)
  • The power of habits in knowledge work (by way of a brief introduction to disciplined approaches in problem solving such as A3 Thinking, for example)

Wrapping Up

Kickstart workshops should always be closed with a summary of what the teams achieved and the next steps that will be taken moving forward. In all instances, some degree of continued coaching and guidance is necessary for teams to optimize their understanding and practice.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020