SEMAT

The Essence Kernel

Quick Reference Guide

                                                 

Version 0.3

              

1. Introduction

This Quick Reference Guides provides a brief introduction to the Essence Kernel. It is designed to support the use of the Essence Cards by software development teams and, in particular, the games that can be played with them. For more detailed information see the SEMAT User Guide available from www.semat.org and the full Essence Specification available from www.omg.org.

The use of the kernel and the cards has many benefits for individuals, teams and organizations. These include helping them to:

• Understand where they are
• Understand what needs to be addressed
• Track progress and health
• Keep projects in balance and avoid catastrophic failures
• Form good sprint goals and other objectives
• Form teams
• Define practice independent checkpoints, milestones and lifecycles.

The Kernel is both simple and incredibly powerful as it 1) captures the key concepts involved in software engineering, 2) allows the progress and health of any software engineering endeavor to be tracked and assessed, and 3) provides the common ground for the definition of software engineering methods and practices. 

1.1 What is Essence?

Essence provides us with a thinking framework that allows teams to understand where they are and acts as a foundation for their way-of-working. At the heart of the Essence approach is the Essence Kernel – a simple state-driven model of software engineering. The Essence Kernel captures the small set of things that are universal to all software engineering endeavors; the things that a team always has to consider or work with when developing software.

The kernel contains seven key elements - Requirements, Software System, Team, Work, Way of Working, Opportunity and Stakeholders. Through states defined on these elements, the kernel provides an intuitive tool for practitioners to reason about the progress and health of their endeavors in a practice-independent way. To distinguish them from the many work products used to describe them these elements are called Alphas. The Alpha view is complemented with two other views 1) a competency-based view of the skill sets the team needs to be able to do them with and 2) an activity focused view of the things that teams always have to do. By populating these views with their practices, teams can quickly assemble, analyze, and share their own way-of-working.

By focusing on the essential things inherent in all software development efforts the Essence Kernel provides a simple definition of the common ground shared by all software development teams regardless of the kind of software being developed, of how the team is organized, of what practices get selected, the size of the system being produced, and the complexity of the problem being addressed.

In summary, the Essence Kernel is a stripped-down, light-weight set of definitions that captures the essence of effective, scalable software engineering in a practice independent way. It gives us a new way to look at the domain of software engineering, a new way to understand the progress and health of our development efforts, and a new way to combine practices into an effective way-of-working. It provides a common reference model all teams can use as they continuously inspect, adapt, and improve their ways of working.

1.2 Presenting the Essence Kernel

The kernel is organized into three discrete areas of concern, each focusing on a specific aspect of software engineering, and each distinguished by the use of a different color. These are:

• Customer – This area of concern contains everything to do with the actual use and exploitation of the software system to be produced. The area of concern and its card are colored green.
• Solution – This area of concern contains everything to do the specification and development of the software system. This area of concern and its cards are colored yellow.

• Endeavor – This area of concern contains everything to do with the team, and the way that they approach their work. This area of concern is colored blue.

Each area of concern contains a small number of:

• Alphas – representations of the essential things to work with. The Alphas provide descriptions of the kind of things that a team will manage, produce, and use in the process of developing, maintaining and supporting software.
• Competencies –representations of the key competencies required to do software engineering.
• Activity Spaces – representations of the essential things to do. The Activity Spaces identify and list generic challenges a team faces when developing, maintaining and supporting software systems, and the kinds of things that the team will do to meet them.

To make the Essence Kernel accessible and easy to use this guide presents the kernel elements in a number of complementary ways. The Alphas and Competencies are presented in overview form and as sets of cards with supporting definitions and checklists. The Activity Spaces are presented purely in overview form.

For example, in this guide, the Alphas are presented using Alpha overview cards, Alpha state cards and full checklists. The cards and checklists used to present the Stakeholder Alpha are shown in Figure 1 below.

Figure 1.  An Alpha overview card, and its accompanying state cards and checklist

Note: The Alpha state cards present an abbreviated view of the Alpha State checklist, useful when using the state cards in a workshop situation. The full checklists show both the abbreviated and full views of the checklist; full checklist items that are viewed as redundant have no abbreviated version and are shown in italics. 

Sets of cards are available from www.semat.org.

2. An Overview of the Alphas

The Alphas do not stand-alone but support each other. The Alphas and their relationships are shown in Figure 2.

Figure 2. The Kernel Alphas

In the customer area of concern the team needs to understand the stakeholders and the opportunity to be addressed:

1. Stakeholders: The people, groups, or organizations who affect or are affected by a software system.

The stakeholders provide the opportunity and are the source of the requirements and funding for the software system. The team members are also stakeholders.  The stakeholders should be involved throughout the software engineering endeavor to support the team and ensure that an acceptable software system is produced.

2. Opportunity: The set of circumstances that makes it appropriate to develop or change a software system.

The opportunity articulates the reason for the creation of the new, or changed, software system. It represents the team's shared understanding of the stakeholders' needs, and helps shape the requirements for the new software system by providing justification for its development.

In the solution area of concern the team needs to establish a shared understanding of the requirements, and implement, build, test, deploy and support a software system that fulfills them:

Requirements: What the software system must do to address the opportunity and satisfy the stakeholders.

It is important to discover what is needed from the software system, share this understanding among the stakeholders and the team members, and use it to drive the development and testing of the new system.

4. Software System: A system made up of software, hardware, and data that provides its primary value by the execution of the software.

The primary product of any software engineering endeavor, a software system can be part of a larger software, hardware or business solution.

In the endeavor area of concern the team and its way-of-working have to be formed, and the work has to be done:

5. Work: Activity involving mental or physical effort done in order to achieve a result.

In the context of software engineering, work is everything that the team does to meet the goals of producing a software system matching the requirements, and addressing the opportunity, presented by the stakeholders. The work is guided by the practices that make up the team's way-of-working.

6. Team: A group of people actively engaged in the development, maintenance, delivery or support of a specific software system.

One or more teams plan and perform the work needed to create, update and/or change the software system.

7. Way-of-Working: The tailored set of practices and tools used by a team to guide and support their work.

The team evolves their way of working alongside their understanding of their mission and their working environment. As their work proceeds they continually reflect on their way of working and adapt it as necessary to their current context.

Each Alpha has a small set of states that are used when assessing progress and health. Associated with each state is a set of pre-defined checklists.  The checklists are available in an abbreviated form, as shown on the cards, and in an expanded form, along with the abbreviated form as shown in tables later in this document.

It should be noted that the states are not just one-way linear progressions.  Each time you reassess a state, if you do not meet all the checklist items, you can go back to a previous state.  You can also iterate through the states multiple times depending on your choice of practices.

The Alphas should not be viewed as a physical partitioning of your endeavor or as just abstract work products.  Rather they represent critical indicators of the things that are most important to monitor and progress.  As an example, team members, while they are part of the Team Alpha, are also stakeholders, and therefore, they can also be part of the Stakeholders Alpha.  In the following sections more detailed information about each of the seven alphas is provided including full state checklists and checklist abbreviations that can also be found on the alpha state cards.  It is recommended that users not use the abbreviations until they have attained a solid understanding of the full checklists.  To aid the use of the Essence framework some redundant checklist items have been suppressed in the abbreviated versions.

2.1 Stakeholders

Stakeholders: The people, groups, or organizations who affect or are affected by a software system.

The stakeholders provide the opportunity, and are the source of the requirements and funding for the software system. They are involved throughout the software engineering endeavor to support the team and ensure that an acceptable software system is produced.

Stakeholders are critical to the success of the software system and the work done to produce it. Their input and feedback help shape the software engineering endeavor and the resulting software system.

Figure 3. Stakeholders: Overview and alpha state cards

 

Table 1. Checklist for Stakeholders 

Recognized: Stakeholders have been identified.
Stakeholder groups identified	All the different groups of stakeholders that are, or will be, affected by the development and operation of the software system are identified.
Key stakeholder groups represented	There is agreement on the stakeholder groups to be represented. At a minimum, the stakeholder groups that fund, use, support, and maintain the system have been considered.
Responsibilities defined	The responsibilities of the stakeholder representatives have been defined.
Represented: The mechanisms for involving the stakeholders are agreed and the stakeholder representatives have been appointed.
Responsibilities agreed	The stakeholder representatives have agreed to take on their responsibilities.
Representatives authorized	The stakeholder representatives are authorized to carry out their responsibilities.
Collaboration approach agreed	The collaboration approach among the stakeholder representatives has been agreed.
Way-of-working supported & respected	The stakeholder representatives support and respect the team's way of working.
Involved: The stakeholder representatives are actively involved in the work and fulfilling their responsibilities.
Representatives assist the team	The stakeholder representatives assist the team in accordance with their responsibilities.
Timely feedback and decisions provided	The stakeholder representatives provide feedback and take part in decision making in a timely manner.
Changes promptly communicated	The stakeholder representatives promptly communicate changes that are relevant for their stakeholder groups.
In Agreement: The stakeholder representatives are in agreement.
Minimal expectations agreed	The stakeholder representatives have agreed upon their minimal expectations for the next deployment of the new system.
Rep's happy with their involvement	The stakeholder representatives are happy with their involvement in the work.
Rep's input valued	The stakeholder representatives agree that their input is valued by the team and treated with respect.
Team's input valued & respected	The team members agree that their input is valued by the stakeholder representatives and treated with respect.
Priorities clear & perspectives balanced	The stakeholder representatives agree with how their different priorities and perspectives are being balanced to provide a clear direction for the team.
Satisfied for Deployment: The minimal expectations of the stakeholder representatives have been achieved.
Stakeholder feedback provided	The stakeholder representatives provide feedback on the system from their stakeholder group perspective.
System ready for deployment	The stakeholder representatives confirm that they agree that the system is ready for deployment.
Satisfied in Use: The system has met or exceeds the minimal stakeholder expectations.
Feedback on system use available	Stakeholders are using the new system and providing feedback on their experiences.
System meets expectations	The stakeholders confirm that the new system meets their expectations.

2.2 Opportunity

Opportunity: The set of circumstances that makes it appropriate to develop or change a software system.

The opportunity articulates the reason for the creation of the new, or changed, software system. It represents the team's shared understanding of the stakeholders' needs, and helps shape the requirements for the new software system by providing justification for its development.

It is the opportunity that unites the stakeholders and provides the motivation for producing a new or updated software system. It is by understanding the opportunity that you can identify the value and the desired outcome that the stakeholders hope to realize from the use of the software system, either alone or as part of a broader business or technical solution.

Figure 4. Opportunity: Overview and alpha state cards

 

Table 2. Checklist for Opportunity 

Identified: A commercial, social or business opportunity has been identified that could be addressed by a software-based solution.
Idea behind opportunity identified	An idea for a way of improving current ways of working, increasing market share, or applying a new or innovative software system has been identified.
At least one investing stakeholder interested	At least one of the stakeholders wishes to make an investment in better understanding the opportunity and the value associated with addressing it.
Other stakeholders identified	The other stakeholders who share the opportunity have been identified.
Solution Needed: The need for a software-based solution has been confirmed.
Solution identified	The stakeholders in the opportunity and the proposed solution have been identified.
Stakeholders' needs established	The stakeholders' needs that generate the opportunity have been established.
Problems and root causes identified	Any underlying problems and their root causes have been identified.
Need for a solution confirmed	It has been confirmed that a software-based solution is needed.
At least one solution proposed	At least one software-based solution has been proposed.
Value Established: The value of a successful solution has been established.
Opportunity value quantified	The value of addressing the opportunity has been quantified either in absolute terms or in returns or savings per time period (e.g., per annum).
Solution impact understood	The impact of the solution on the stakeholders is understood.
System value understood	The value that the software system offers to the stakeholders that fund and use the software system is understood.
Success criteria clear	The success criteria by which the deployment of the software system is to be judged are clear.
Outcomes clear and quantified	The desired outcomes required of the solution are clear and quantified.
Viable: It is agreed that a solution can be produced quickly and cheaply enough to successfully address the opportunity.
Solution outlined	A solution has been outlined.
Rep's happy with their involvement	The stakeholder representatives are happy with their involvement in the work.
Solution possible within constraints.	The indications are that the solution can be developed and deployed within constraints.
Risks acceptable & manageable	The risks associated with the solution are acceptable and manageable.
Solution profitable	The indicative (ball-park) costs of the solution are less than the anticipated value of the opportunity.
Reasons to develop solution understood	The reasons for the development of a software-based solution are understood by all members of the team.
	It is clear that the pursuit of the opportunity is viable.
Addressed: A solution has been produced that demonstrably addresses the opportunity.
Opportunity addressed	A usable system that demonstrably addresses the opportunity is available.
Solution worth deploying	The stakeholders agree that the available solution is worth deploying.
Stakeholders satisfied	The stakeholders are satisfied that the solution produced addresses the opportunity.
Benefit Accrued: The operational use or sale of the solution is creating tangible benefits.
Solution accrues benefits	The solution has started to accrue benefits for the stakeholders.
ROI acceptable	The return-on-investment profile is at least as good as anticipated.

2.3 Requirements

Requirements: What the software system must do to address the opportunity and satisfy the stakeholders.

It is important to discover what is needed from the software system, share this understanding among the stakeholders and the team members, and use it to drive the development and testing of the new system.

The requirements are captured as a set of requirement items. The requirement items can be communicated and recorded in various forms and at various levels of detail. It is important that the overall state of the requirements is understood as well as the state of the individual requirement items. Amongst other things this will help you tell when the system is finished, and judge whether or not an individual requirement item is in scope.

Figure 5. Requirements: Overview and alpha state cards

 

Table 3. Checklist for Requirements

Conceived: The need for a new system has been agreed.
Stakeholders agree system is to be produced	The initial set of stakeholders agrees that a system is to be produced.
Users identified	The stakeholders that will use the new system are identified.
Funding stakeholders identified	The stakeholders that will fund the initial work on the new system are identified.
Opportunity clear	There is a clear opportunity for the new system to address.
Bounded: The purpose and theme of the new system are clear.
Development stakeholders identified	The stakeholders involved in developing the new system are identified.
System purpose agreed	The stakeholders agree on the purpose of the new system.
System success clear	It is clear what success is for the new system.
Shared solution understanding exists	The stakeholders have a shared understanding of the extent of the proposed solution.
Requirements' format agreed	The way the requirements will be described is agreed upon.
Requirements management in place	The mechanisms for managing the requirements are in place.
Prioritization scheme clear	The prioritization scheme is clear.
Constraints identified & considered	Constraints are identified and considered.
Assumptions clearly	Assumptions are clearly stated.
Coherent: The requirements provide a consistent description of the essential characteristics of the new system.
Requirements shared	The requirements are captured and shared with the team and the stakeholders.
Requirements' origin clear	The origin of the requirements is clear.
Rationale clear	The rationale behind the requirements is clear.
Conflicts addressed	Conflicting requirements are identified and attended to.
Essential characteristics clear	The requirements communicate the essential characteristics of the system to be delivered.
Key usage scenarios explained	The most important usage scenarios for the system can be explained.
Priorities clear	The priority of the requirements is clear.
Impact understood	The impact of implementing the requirements is understood.
Team knows & agrees on what to deliver	The team understands what has to be delivered and agrees to deliver it.
Acceptable: The requirements describe a system that is acceptable to the stakeholders.
Acceptable solution described	The stakeholders accept that the requirements describe an acceptable solution.
Change under control	The rate of change to the agreed requirements is relatively low and under control.
Value to be realized clear	The value provided by implementing the requirements is clear.
Clear how opportunity addressed	The parts of the opportunity satisfied by the requirements are clear.
Testable	The requirements are testable.
Addressed: Enough of the requirements have been addressed to satisfy the need for a new system in a way that is acceptable to the stakeholders.
Enough addressed to be acceptable	Enough of the requirements are addressed for the resulting system to be acceptable to the stakeholders.
Requirements and system match	The stakeholders accept the requirements as accurately reflecting what the system does and does not do.
Value realized clear	The set of requirement items implemented provide clear value to the stakeholders.
System worth making operational	The system implementing the requirements is accepted by the stakeholders as worth making operational.
Fulfilled: The requirements that have been addressed fully satisfy the need for a new system.
Stakeholders accept requirements	The stakeholders accept the requirements as accurately capturing what they require to fully satisfy the need for a new system.
No hindering requirements	There are no outstanding requirement items preventing the system from being accepted as fully satisfying the requirements.
Requirements fully satisfied	The system is accepted by the stakeholders as fully satisfying the requirements.

 

2.4 Software System

Software System: A system made up of software, hardware, and data that provides its primary value by the execution of the software.

A software system can be part of a larger software, hardware, business or social solution.

We use the term software system rather than software because software engineering results in more than just a piece of software. Whilst the value may well come from the software, a working software system depends on the combination of software, hardware and data to fulfill the requirements.

Figure 6.  Software System: Overview and alpha state cards

 

Table 4. Checklist for Software System

Architecture Selected: An architecture has been selected that addresses the key technical risks and any applicable organizational constraints.
Architecture selection criteria agreed	The criteria to be used when selecting the architecture have been agreed on.
HW platforms identified	Hardware platforms have been identified.
Technologies selected	Programming languages and technologies to be used have been selected.
System boundary known	System boundary is known.
Decisions on system organization made	Significant decisions about the organization of the system have been made.
Buy, build, reuse decisions made	Buy, build, and reuse decisions have been made.
Key technical risks agreed to	Key technical risks agreed to.
Demonstrable: An executable version of the system is available that demonstrates the architecture is fit for purpose and supports testing.
Key architectural characteristics demonstrated	Key architectural characteristics have been demonstrated.
System exercised & performance measured	The system can be exercised and its performance can be measured.
Critical HW configurations demonstrated	Critical hardware configurations have been demonstrated.
Critical interfaces demonstrated	Critical interfaces have been demonstrated.
Integration with environment demonstrated	The integration with other existing systems has been demonstrated
Architecture accepted as fit-for-purpose	The relevant stakeholders agree that the demonstrated architecture is appropriate.
Usable: The system is usable and demonstrates all of the quality characteristics of an operational system.
System can be operated	The system can be operated by stakeholders who use it.
System functionality tested	The functionality provided by the system has been tested.
System performance acceptable	The performance of the system is acceptable to the stakeholders.
Defect levels acceptable	Defect levels are acceptable to the stakeholders.
System fully documented	The system is fully documented.
Release content known	Release content is known.
Added value clear	The added value provided by the system is clear.
Ready: The system (as a whole) has been accepted for deployment in a live environment.
User documentation available	Installation and other user documentation are available.
System accepted as fit-for-purpose	The stakeholder representatives accept the system as fit-for-purpose.
Stakeholders want the system	The stakeholder representatives want to make the system operational.
Operational support in place	Operational support is in place.
Operational: The system is in use in an operational environment.
System available for use	The system has been made available to the stakeholders intended to use it.
System live	At least one example of the system is fully operational.
SLAs supported	The system is fully supported to the agreed service levels.
Retired: The system is no longer supported.
Replaced or discontinued	The system has been replaced or discontinued.
No longer supported	The system is no longer supported.
No authorized users	There are no "official" stakeholders who still use the system.
Updates stopped	Updates to the system will no longer be produced.

2.5 Team

Team: A group of people actively engaged in the development, maintenance, delivery or support of a specific software system.

One or more teams plan and perform the work needed to create, update and/or change the software system.

Software engineering is a team sport involving the collaborative application of many different competencies and skills. To achieve high performance, team members should reflect on how well they work together, and relate this to their potential and effectiveness in achieving their mission.

Normally a team consists of several people. Occasionally, however, work may be undertaken by an individual creating software purely for their own use and entertainment. A team requires at least two people, but most of the guidance provided by the Team Alpha can also be used to help single individuals when creating software.

Figure 7. Team: Overview and alpha state cards

 

Table 5. Checklist for Team

Seeded: The team's mission is clear and the know-how needed to grow the team is in place.
Mission defined	The team mission has been defined in terms of the opportunities and outcomes.
Constraints known and defined	Constraints on the team's operation are known.
Growth mechanisms in place	Mechanisms to grow the team are in place.
Composition defined	The composition of the team is defined.
	Any constraints on where and how the work is carried out are defined.
Responsibilities outlined	The team's responsibilities are outlined.
Required commitment level clear	The level of team commitment is clear.
Required competencies identified	Required competencies are identified.
Size determined	The team size is determined.
Governance rules defined	Governance rules are defined.
Leadership model selected	Leadership model is selected.
Formed: The team has been populated with enough committed people to start the mission.
	Individual responsibilities are understood.
Enough members recruited	Enough team members have been recruited to enable the work to progress.
Roles understood	Every team member understands how the team is organized and what their individual role is.
How to work understood	All team members understand how to perform their work.
Members introduced	The team members have met (perhaps virtually) and are beginning to get to know each other.
Individual responsibilities understood and  aligned to competencies	The team members understand their responsibilities and how they align with their competencies.
Members accepting work	Team members are accepting work.
External collaborators identified	Any external collaborators (organizations, teams and individuals) are identified.
Communication mechanisms defined	Team communication mechanisms have been defined.
Members commit to team	Each team member commits to working on the team as defined.
Collaborating: The team members are working together as one unit.
Works as one unit	The team is working as one cohesive unit.
Communication open and honest	Communication within the team is open and honest.
Focused on mission	The team is focused on achieving the team mission.
Members know each other	The team members know each other.
Performing: The team is working effectively and efficiently.
Consistently meeting commitments	The team consistently meets its commitments.
Continuously adapting to change	The team continuously adapts to the changing context.
Addresses problems	The team identifies and addresses problems without outside help.
Rework and backtracking minimized	Effective progress is being achieved with minimal avoidable backtracking and reworking.
Waste continuously eliminated	Wasted work, and the potential for wasted work are continuously eliminated.
Adjourned: The team is no longer accountable for carrying out its mission.
Responsibilities fulfilled	The team responsibilities have been handed over or fulfilled.
Members available to other teams	The team members are available for assignment to other teams.
Mission concluded	No further effort is being put in by the team to complete the mission.

 

2.6 Work

Work: Activity involving mental or physical effort done in order to achieve a result.

In the context of software engineering, work is everything that the team does to meet the goals of producing a software system matching the requirements and addressing the opportunity presented by the stakeholders. The work is guided by the practices that make up the team's way-of-working.

The ability of team members to co-ordinate, organize, estimate, complete, and share their work has a profound effect on meeting their commitments and delivering value to their stakeholders. Team members need to understand how to carry out their work, and how to recognize when the work is going well.

Figure 8. Work: Overview and alpha state cards

 

Table 6. Checklist for Work

Initiated: The work has been requested.
Required result clear	The result required of the work being initiated is clear.
Constraints clear	Any constraints on the work's performance are clearly identified.
Funding stakeholders known	The stakeholders that will fund the work are known.
Initiator identified	The initiator of the work is clearly identified.
Accepting stakeholders known	The stakeholders that will accept the results are known.
Source of funding clear	The source of funding is clear.
Priority clear	The priority of the work is clear.
Prepared: All pre-conditions for starting the work have been met.
Commitment made	Commitment is made.
Cost and effort estimated	Cost and effort of the work are estimated.
Resource availability understood	Resource availability is understood
	Governance policies and procedures are clear.
Risk exposure understood	Risk exposure is understood.
Acceptance criteria established	Acceptance criteria are defined and agreed with client.
Sufficiently broken down to start	The work is broken down sufficiently for productive work to start.
Tasks identified and prioritized	Tasks have been identified and prioritized by the team and stakeholders.
Credible plan in place	A credible plan is in place.
Funding in place	Funding to start the work is in place.
At least one team member ready to start	The team or at least some of the team members are ready to start the work.
Integration points defined	Integration and delivery points are defined.
Started: The work is proceeding.
Development started	Development work has been started.
Progress monitored	Work progress is monitored.
Definition of done in place	The work is being broken down into actionable work items with clear definitions of done.
Tasks being progressed	Team members are accepting and progressing tasks.
Under Control: The work is going well, risks are under control, and productivity levels are sufficient to achieve a satisfactory result.
Tasks being completed	Tasks are being completed.
Unplanned work under control	Unplanned work is under control.
Risks under control	Risks are under control as the impact if they occur and the likelihood of them occurring have been reduced to acceptable levels.
Estimates revised to reflect performance	Estimates are revised to reflect the team's performance.
Progress measured	Measures are available to show progress and velocity.
Re-work under control	Re-work is under control.
Commitments consistently met	Tasks are consistently completed on time and within their estimates.
Concluded: The work to produce the results has been concluded.
Only admin tasks left	The team responsibilities have been handed over or fulfilled.
Results achieved	The team members are available for assignment to other teams.
Resulting system accepted	No further effort is being put in by the team to complete the mission.
Closed: All remaining housekeeping tasks have been completed and the work has been officially closed.
Lessons learned	Lessons learned have been itemized, recorded and discussed.
Metrics available	Metrics have been made available.
Everything archived	Everything has been archived.
Budget reconciled & closed	The budget has been reconciled and closed.
Team released	The team has been released.
No outstanding, uncompleted tasks	There are no outstanding, uncompleted tasks.

Download

Kernel Quick Reference Guide