=== GENERAL ===

*   *   *

Question G01: Some of the Alpha State names and definitions appear ambiguous.  How can I get more information about what is required to achieve these ambiguous states?

Answer G01:  To get the best definition on each state refer to the full checklist items.  In some cases there still may be a degree of ambiguity such as in phrases like "agreed to", and "sufficient".   In these cases the team should discuss the checklist focusing on the team's specific context to reach a decision. 

*   *   *

Question G02:  Are some alpha state checklist items "automatically" achieved when you satisfy certain checklist items in other  alphas?

Answer G02: No.  Each checklist item should be considered from the context of the alpha it is a part of – taking a different perspective of the same phenomenon.  While some checklist items seem closely related and possibly the same as a checklist item in another alpha, when you consider each alpha checklist from its own alpha perspective distinctions often become apparent.

*   *   *

Question G03: What size of work should the Essence framework be applied to?

Answer G03: The Software System Alpha was developed with a focus on "major releases".  However, it can be applied to smaller pieces of work such as a sprint. (See also answer G04).

*   *   *

Question G04: What is meant by the word "system" and why do we sometimes refer to "new system"?

Answer G04: When applying Essence, the primary goal is to deliver working software that addresses an opportunity which was identified by stakeholders. Depending on the situation, "working software" can apply to: a new system or changes to an existing system (maintenance or enhancements).

When a team applies Essence for the first time, it is important to agree on the meaning of the word "system" in the particular context of the current endeavor and to be mindful of this meaning throughout.

*   *   *

Question G05: Essence uses the term "risk" in ways that seem to imply negative risk – things that can go wrong. Where does Essence make provision for the serendipitous occurrence of positive risk - unexpected events that are welcomed?

Answer G05: Alpha state checklist items are result based, i.e. they are not intended to name any risk specifically. On the contrary checklists provide users with a thinking framework designed to help teams debate  about possible negative and positive risks that can impede or be conducive to achieving result. 

*   *   *

Question G06: The term "Work Requirements" is used in several of the Generic Competency Levels checklist items describing competency levels 2 (Applies), 3 (Masters) and 4 (Adapts). What are "Work Requirements". Are these a special type of requirements?

Answer G06:  The competency levels are applicable to all 6 of the competencies. So in this context work refers to the work to be done by the competency, for example the work of a developer vs. the work of an analyst. Work requirements then means the requirements or expectations for the particular competency.

 

=== OPPORTUNITY ===

*   *   *

Question O01: The Opportunity Viable state is described as:  It is agreed that a solution can be produced quickly and cheaply enough to successfully address the opportunity.  Why does it need to be "cheap" to be viable?

Answer O01: The intent of the description of the Opportunity Viable state is not to imply that the solution needs to be "cheap", but rather that it can be produced in an affordable way.  Perhaps the word "affordable" would have been a better choice than the phrase "cheaply enough". 

*   *   *

Question O02: How should we interpret the intent of the checklist item, "The return-on-investment profile is at least as good as anticipated" in the Benefit Accrued state of the Opportunity Alpha?

Answer O02: The intent of this checklist item is to determine if the intent of the software system is being achieved, or if investor confidence is being maintained. 

*   *   *

Question O03: A checklist item of the Identified state of the Opportunity Alpha is phrased as follows: "The other stakeholders who share the opportunity have been identified". Is this checklist item not satisfied by achievement of the Recognized state of the Stakeholder Alpha? And as such, is it not a duplication to include it in the Opportunity Alpha?

Answer O03: While it seems as if this checklist item will automatically have been satisfied by virtue of achieving a certain state in another alpha, it is not advised that automatic achievement be claimed. The checklist item should still be considered on its own merit within the context of this alpha state. (See also Answer G02). As an example, when considering stakeholders specifically from the opportunity perspective it is possible that certain stakeholders may be considered that otherwise might be missed when looking at stakeholders in general from the stakeholder perspective.

*   *   *

Question O04: Two checklist items of the Value Established state of the Opportunity Alpha are phrased as follows:

  • "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)".
  • "The value that the software system offers to the stakeholders that fund and use the software system is understood".

Why are 2 separate checklist items required? Will it ever happen that one can be satisfied without the other? Should the checklist items not be combined?

Answer O04: The first checklist item places the emphasis on having done the work to quantify the value of addressing the opportunity. The second checklist item focuses on making sure that funders have understood the value and accept that it is economically feasible.

*   *   *

Question O05: Two checklist items of the Viable state of the Opportunity Alpha deal with the solution. How is "A solution has been outlined" different from "At least one software-based solution has been proposed"?

Answer O05: A solution can be proposed on the basis of a very sketchy understanding, while the outlined solution suggests that work has been performed to go beyond the initial proposal.

*   *   *

Question O06: The last checklist item of the Viable state of the Opportunity Alpha seems to be superfluous. ("It is clear that the pursuit of the opportunity is viable"). What evidence will be used to declare it as having been achieved? (It just seems to be describing the state achieved by satisfying the other checklist items on this card).

Answer O06: The last checklist item could well be redundant – no additional evidence is required to mark it up as having been satisfied.

*   *   *

Question O07: A checklist item of the Addressed state of the Opportunity Alpha is phrased as follows: "The stakeholders agree that the available solution is worth deploying". This seems to be duplicating the Stakeholder alpha state "Satisfied for Deployment". Is this checklist item required?

Answer O07: Both checklist items are required: a solution that is worth deploying is not automatically ready for deployment – and vice versa.

*   *   *

Question O08: A checklist item of the Benefit Accrued state of the Opportunity Alpha is phrased as follows: "The return-on-investment profile is at least as good as anticipated". Is it realistic to require the ROI profile to always come out at least as good as expected – or is this checklist item asking too much? (Many software endeavors are executed in the absence of a formal ROI expectation, and those that do often find that the ROI expectation is not realized). Should the checklist item not rather ask about realization of what we had hoped to achieve and whether investor confidence has been maintained?

Answer O08: Essence provides a framework against which the progress and health of software endeavors can be tested. While it might be necessary to sometimes rather focus on realization of hopes and sustaining investor confidence, a more manageable (and healthy?) outcome would be to measure performance against an ROI target. What is essential is that each team considers what is keeping it from satisfying the checklist/s, and then decides if these are issues that they need to do something about — given their specific context. In some situations it may be necessary for the team to decide, based on context whether to interpret ROI literally or to interpret this as "hopes and sustaining stakeholder confidence". (Refer PEM Whitepaper #1 for more detail).

 

=== REQUIREMEMENTS ===

*   *   *

Question R01: Four checklist items of the Requirements Conceived state are phrased as follows:

  • "The initial set of stakeholders agrees that a system is to be produced".
  • "The stakeholders that will use the new system are identified".
  • "The stakeholders that will fund the initial work on the new system are identified".
  • "There is a clear opportunity for the new system to address".

Are these 4 checklist items not just a duplication of items addressed by the Stakeholders and Opportunity alphas?

Answer R01: These checklist items reinforce the importance of these items in context of this alpha – conceived requirements. While it seems as if these checklist items will automatically have been satisfied by virtue of achieving certain state/s in other alpha/s, it is not advised that automatic achievement be claimed. The checklist items should still be considered on their own merit within the context of this alpha state. (See also Answer G02).  As an example, when thinking about the stakeholders that will use the new system from the requirements perspective, some stakeholders may come to mind that are missed when thinking about stakeholders in general from the stakeholder alpha perspective. 

*   *   *

Question R02: A checklist item of the Bounded state of the Requirements Alpha is phrased as follows: "The stakeholders involved in developing the new system are identified". Is this checklist item not just a duplication of what is addressed by the Stakeholders Alpha? And as such, is it not a duplication to include it in the Requirements Alpha?

Answer R02: While it seems as if this checklist item will automatically have been satisfied by virtue of achieving a certain state in another alpha, it is not advised that automatic achievement be claimed. The checklist item should still be considered on its own merit within the context of this alpha state. (See also Answer G02).

*   *   *

Question R03: A checklist item of the Bounded state of the Requirements Alpha reads: "The prioritization scheme is clear". How is this different from work prioritization?

Answer R03: Requirements prioritization sets the scene for work prioritization related to satisfying requirements, but there is also other work that is not directly related to requirements. (The checklist item could be understood to read: "The requirements prioritization scheme is clear").

*   *   *

Question R04: Two checklist items of the Bounded state of the Requirements Alpha are phrased as follows:

  • "Constraints are identified and considered".
  • "Assumptions are clearly stated".

Do these not relate more to planning of work?

Answer R04: While it seems as if these checklist items will automatically have been satisfied by virtue of achieving a certain state in another alpha, it is not advised that automatic achievement be claimed. The checklist items should still be considered on their own merit within the context of this alpha state. (See also Answer G02). It might be helpful to precede each checklist item with the word "requirement".  As an example, when thinking specifically about requirements assumptions, or requirements constraints, certain assumptions or constraints may come to mind that are different from work constraints and assumptions. 

*   *   *

Question R05: A checklist item of the Coherent state of the Requirements Alpha reads: "The priority of the requirements is clear". Is it necessary to deal with priority again?

Answer R05: Prioritization was previously dealt with at scheme level. Now prioritization has been done with all known requirements being taken into account. As an example the requirements prioritization scheme may be "the use/customer representative will prioiritize requirements". When the  requirements have been prioritized for a particular sprint or release, this checklist item has been met.

*   *   *

Question R06: A checklist item of the Coherent state of the Requirements Alpha reads: "The team understands what has to be delivered and agrees to deliver it". Should this checklist item not be part of the Team alpha?

Answer R06: Here the emphasis is on the team's understanding of the requirements and whether requirements have been formulated in an understandable way.

*   *   *

Question R07: A checklist item of the Acceptable state of the Requirements Alpha reads: "Rate of change … relatively low". This seems to reflect a plan-driven, controlled quality approach. In agile, crafted quality endeavors, high rates of change are regularly accepted. Is it always possible/necessary to satisfy this checklist item?

Answer R07: Accomplishment of this checklist item becomes more achievable if one emphasizes that the focus is on agreed requirements. It is also important to realize that Essence provides a framework against which the progress and health of software endeavors can be tested. While it might be necessary to sometimes accept a rather high rate of requirements volatility, a more manageable (and healthy?) outcome would be to stabilize requirements. What is essential is that each team considers what is keeping it from satisfying the checklist/s, and then decides if these are issues that they need to do something about — given their specific context. (Refer PEM Whitepaper #1 for more detail).

*   *   *

Question R08: A checklist item of the Acceptable state of the Requirements Alpha is phrased as follows: "The value provided by implementing the requirements is clear". Is this checklist item not satisfied while progressing the Opportunity Alpha? And as such, is it not a duplication to include it in the Requirements Alpha?

Answer R08: The overall value of the opportunity could be different to the value of implemented requirements. Value derived by implementing the requirements could be understood in terms of benefits realization - the benefits of implementing the requirements and which contribute to overall value delivery.

*   *   *

Question R09: Two checklist items of the Requirements Addressed state are phrased as follows:

  • "The stakeholders accept the requirements as accurately reflecting what the system does and does not do".
  • "The system implementing the requirements is accepted by the stakeholders as worth making operational".

Is this state not achieved as part of the Software System Alpha? ("The stakeholder representatives accept the system as fit-for-purpose").

Answer R09: The checklist items of the Requirements Alpha relate to verification against system specification and design and validation against requirements. But a known shortcoming of software engineering is that a system may pass these tests and still not really be fit for purpose.

 

=== SOFTWARE SYSTEM ===

*   *   *

Question SS01: Two checklist items of Software System Usable state are phrased as follows:

  • "The system is fully documented".
  • "Installation and other user documentation are available".

 This seems to reflect a plan-driven, controlled quality approach. In agile, crafted quality endeavors, documentation is often given much less attention. Should this not read: "The system is appropriately documented according to agreed documentation requirements"?

Answer SS01: The suggested re-phrasing is acceptable and communicates the intention of the checklist items.

 

=== STAKEHOLDERS ===

*   *   *

Question SH01: On the Stakeholders Alpha description card, the meaning of the In Agreement alpha state is described as follows: "The stakeholder representatives are in agreement". What are they in agreement about?

Answer SH01: The stakeholder representatives have agreed upon their minimal expectations for the next deployment of the system, that their input is valued and treated with respect, and with how their priorities and perspectives are being balanced to provide a clear direction for the team.

*   *   *

Question SH02: On the Stakeholders Alpha description card, two alpha states (Satisfied for Deployment and Satisfied in Use) make reference to "minimal expectations". Why is this when the scope of delivery is often aimed at more than the minimum?

Answer SH02: The words "minimal expectations" imply what stakeholders are all in agreement about and the scope of this agreement will vary from one situation to another.

 

=== TEAM ===

*   *   *

Question T01: One of the requirements for achieving Team Seeded state is: "Mechanisms to grow the team are in place". The checklist item assumes that the team must grow. But what if the team is already at its optimal size? Should the checklist item not be phrased to: "Mechanisms to sustain and/or grow the team are in place"?

Answer T01: The suggested re-phrasing is acceptable and accurately communicates the intention of the checklist item.

*   *   *

Question T02: One of the requirements for achieving Team Seeded state is: "Any constraints on where and how the work is carried out are defined". Should the constraints of where and how work is to be carried out not be achieved as part of the Work alpha?

Answer T02: When forming the team, some constraints related to team functioning need to be known. Work constraints are another matter. For example, a team constraint might refer to times when individual team members are available to work.

*   *   *

Question T04: Team Seeded state needs "Governance rules are defined" to be accomplished. Should rules of governance not be defined as part of the Work Alpha?

Answer T04: This checklist item places the emphasis on rules of governance that affect behavior of the team. Additional rules are defined to regulate execution of work. (See Work Alpha – Prepared state).

*   *   *

Question T07: Team Collaborating requires that "The team members know each other". What has to happen for one to claim accomplishment of this checklist item? What does it mean for team members to "know each other"?

Answer T07: Team members have at least been introduced and contact details shared.

*   *   *

Question T09: A checklist item that relates to the Team Adjourned state reads: "The team members are available for assignment to other teams". Does this mean that in order to fulfill this checklist item, team members must be assigned to other teams?

Answer T09: Exactly what it means to satisfy this checklist item is defined by the particular situation. Being available for assignment to other teams does not mean that actual re-assignment will occur.

=== WAY OF WORKING ===

*   *   *

Question WW01: A number of checklist items of Way of Working Foundation Established, In Use and In Place all make reference to "…practices and tools …". Is it reasonable to always link practices and tools? Some teams place the emphasis on practices and others on tools. Should practices and tools not be dealt with separately rather than as part of the same checklist items?

Answer WW01: A healthy condition requires awareness of both practices and tools. But the checklist items could be taken to mean practices and/or tools in specific situations.

 

=== WORK ===

*   *   *

Question W01: A checklist item of the Initiated state of the Work Alpha is phrased as follows: "The stakeholders that will fund the work are known". The conditions required to satisfy this checklist item are accomplished as part of the Stakeholder alpha – is this a duplication?

Answer W01: While it seems as if this checklist item will automatically have been satisfied by virtue of achieving a certain state in another alpha, it is not advised that automatic achievement be claimed. The checklist item should still be considered on its own merit within the context of this alpha state. 

*   *   *

Question W02: Two checklist items of the Initiated state of the Work Alpha are phrased as follows:

  • "The stakeholders that will fund the work are known".
  • "The source of funding is clear".

These checklist items seem to be inter-related. Can the one be accomplished without the other? Should they not be combined?

Answer W02: The source refers to the mechanism to get hold of the funds and as such is different from knowing the stakeholders who will fund the work.

*   *   *

Question W03: A checklist item of the Prepared state of the Work Alpha is phrased as follows: "Integration and delivery points are defined". Is definition of integration and delivery points not specific to the software solution, rather than a generic part of Work?

Answer W03: Achievement of the Prepared state involves making sure that essential planning of work has been done, and as a minimum, attention must have been given to planning for the integration and delivery points.

*   *   *

Question W04: A checklist item of the Started state of the Work Alpha is phrased as follows: "The work is being broken down into actionable work items with clear definitions of done". How is this different from the checklist item of the Prepared state that reads: "The work is broken down sufficiently for productive work to start"?

Answer W04: "Clear definitions of done" (as decided by the team) makes the difference. Actionable work items could be at a lower level of detail than what was achieved for the Prepared state.

*   *   *

Question W06: A checklist item of the Concluded state of the Work Alpha is phrased as follows: "The stakeholder(s) has accepted the resulting software system". The conditions required to satisfy this checklist item are accomplished as part of the Stakeholder Alpha – is this a duplication?

Answer W06: While it seems as if this checklist item will automatically have been satisfied by virtue of achieving a certain state in another alpha, it is not advised that automatic achievement be claimed. The checklist item should still be considered on its own merit within the context of this alpha state. (Refer PEM Whitepaper #2 for more detail).

*   *   *

Question W08: Achieving the Closed state of the Work Alpha includes "The team has been released". Does this mean that in order to fulfill this checklist item, team members must be assigned to other teams?

Answer W08: "The team has been released" means released from this piece of work. The team may go on to more of the same or more different work. The team having been released does not imply that it has been adjourned.