ESSENCE-POWERED SCRUM - A GENERIC APPROACH TO DESCRIBING PRACTICES USING ESSENCE KERNEL AND LANGUAGE
PROFESSOR JUNE SUNG PARK, KAIST / SEMAT
ALPHA
Alpha represents things to
deal with in any software
engineering project.
3
Cu
sto
me
r So
luti
on
En
de
avo
r
Opportunity Stakeholders
Requirements Software System
Work Team
Way of Working
<provide
use an
d
con
sum
e> <p
rod
uces
scop
es and
co
nstrain
ts>
focu
ses>
<fulfills
<performs and plans
<set up
to ad
dress
Sup
po
rt>
* Alpha means “Abstract-Level
Progress Health Attribute.”
ALPHA DECOMPOSITION AND EXTENSION
An alpha may have lower-level, more granule
sub-alphas whose states contribute to and drive
the state of the super-alpha.
• Association between super-alphas and sub-alphas
can be many-to-many.
An alpha may be Extended (i.e., have the values
of its attributes be changed) in the context of a
Practice (such as Scrum).
7
Alpha Sub-Alpha
Alpha Extended Alpha
ACTIVITY SPACE
Activity spaces are containers of activities performed in a project.
• An activity may be a part of another activity forming a work breakdown structure.
The association between activity spaces and activities can be many-to-many.
8
Cu
sto
me
r So
luti
on
En
de
avo
r
Explore Possibilities
Understand Stakeholder Needs
Ensure Stakeholder Satisfaction Use the System
Understand the Requirements
Shape the System
Implement the System
Test the System
Deploy the System
Operate the System
Prepare to do the Work
Coordinate the Activity Support Team Track Progress Stop the Work
ACTIVITY SPACE AND ALPHA STATE
Pre and post conditions of
each activity space are
suggested (as a reference)
in terms of alpha states in
the kernel.
9
Alpha States
Activity Spaces
Opportunity Stakeholder
Ide
nti
fie
d
Solu
tio
n
Ne
ed
ed
Val
ue
Es
tab
lish
ed
Via
ble
Ad
dre
sse
d
Be
nef
it
Acc
rue
d
Re
cogn
ize
d
Re
pre
sen
ted
Invo
lve
d
In A
gre
em
en
t
Sati
sfie
d f
or
De
plo
yme
nt
Sati
sfie
d
in U
se
Explore Possibilities
Understand Stakeholder Needs
Ensure Stakeholder Satisfaction
Use the System
ESSENCE KERNEL EXTENSION
Patterns can arrange language
elements into arbitrary
meaningful structures.
Resources can be attached to any
language element.
Tags add user defined information
to any language element.
User-Defined Types detail, explain,
and constrain the proper usage of
particular patterns, resources, or
tags.
10
METHOD DESCRIPTION IN ESSENCE LANGUAGE
There are probably hundred
thousands of methods applied in
SE projects worldwide.
There are about 300 well known
practices reusable across projects.
Those practices can be described
using Essence kernel and language.
A project method can be
composed of practices.
12
Practices
Methods
Custom Method A Custom Method B are composed of
are described using
are defined in terms of
Essence Kernel
Essence Language
OMG Standard
ESSENCE KERNEL AND METHOD 13
Alpha
Alpha State
Activity Space
Competency
Work Product
Activity
<has
ta
rgets
> defines
/
pro
duce
s /
updat
es>
Work
Task
< defines
Approach
defines
one w
ay t
o a
ccom
plis
h >
Practice
< is composed of
Method
PRACTICE DESCRIPTION IN ESSENCE LANGUAGE
A software engineering practice can be
described in Essence language by
mapping:
• work products to Alphas,
• activities to Activity Spaces
• roles to Competencies
Mapping a practice to Essence
produces a mapping from activities to
“default” state transitions.
14
Practice
Work Product
Activity
Role
Essence Kernel
Alpha
Alpha State
Activity Space
Competency
ACTIVITY AND STATE TRANSITION
Activities may change the alpha states of
the software engineering project.
Activities can be assigned target alpha
states or checkpoints (i.e. criteria of
done).
By mapping activities to activity spaces
you can get “default” target states of each
activity.
15
Activity Space
Competency
Activity
targ
ets>
pro
du
ces
/ u
pd
ates
>
Alpha
Alpha State
Work Product
<has
COMPETENCY AND ROLE
The role can be modeled as a Pattern.
Patterns can arrange language elements into
arbitrary meaningful structures.
16
Cu
sto
mer
So
luti
on
E
nd
eavo
r
Stakeholder Representation
Analysis Development Testing
Leadership Management
Role
profiles>
Is q
ual
ifie
d
to p
erfo
rm>
organizes> Alpha
Alpha State
Activity Space
Competency
Activity
<has
ta
rget
s>
pro
du
ces
/ u
pd
ate
s>
Work Product
PRACTICE DESCRIPTION APPROACH
1. Build an Ontology of the Terms used in the Practice
Parse the text description of the Practice to build a Glossary.
Classify the Terms in the Glossary into Work Products, Activities, Roles, etc.
Add missing Terms such as activities for producing or updating work products and vice versa.
2. Map the Terms to Essence Language Elements.
Determine alphas, alpha states and checkpoints corresponding to each work product.
Determine activity spaces, beginning and target alpha states, target checkpoints corresponding to each activity.
Determine competencies required of different roles.
3. Decompose and Extend Essence Kernel Elements to represent detailed concepts, composite constructs and complex relationships.
Define sub-alphas, sub-activity spaces, patterns, resources and tags to represent concepts in the practice.
17
Build Practice
Ontology
Map Terms to Essence
Language Elements
Decompose and
Extend Essence Kernel
Elements if necessary
SCRUM PRACTICE 18
Development Team
Task
Breakdown
Product Increment
Jeff Sutherland and Ken Schwaber, The Scrum Guide, 2013. (http://www.scrumguides.org/)
SCRUM GLOSSARY
Key Terms Classification Relationship
Added Terms Role Activity Work Product
Daily Scrum Activity Development Team Sprint Plan, Total Work Remaining
Definition of Done Work Product Sprint Retrospective Increment, Product Backlog Refinement
Developer Role
Development Team Role Daily Scrum Sprint Backlog, Development Work, Increment
Development Work Activity Sprint Backlog, Development Work Plan, Work Unit,
Increment
Development Work
Plan
Improvement Plan Work Product Sprint Retrospective
Increment Work Product Sprint Review Sprint Plan, Sprint Goal, Sprint Backlog, Definition of
Done
Product Backlog Work Product Product Owner Product Backlog Refinement,
Sprint Review Product Backlog Item
Product Backlog
Creation
Product Backlog Item Work Product Product Backlog
Product Backlog Refinement Activity Product Backlog
Product Owner Role
Product Backlog Creation,
Product Backlog Refinement,
Sprint Review
Product Backlog Product Backlog
Creation
Scrum Event Composite Activity
Scrum Master Role Sprint Retrospective
Scrum Team Work Product PO, DT, SM
Sprint Milestone
Sprint Backlog Work Product Development Team Product Backlog, Sprint Goal, Development Work
Sprint Goal Work Product Sprint Planning Sprint Planning
Sprint Plan Composite Work Product
Sprint Planning Activity Sprint Plan
Sprint Retrospective Activity Scrum Master Sprint Plan, Definition of Done,
Sprint Review Activity Stakeholders, Increment, Product Backlog, Total Work Remaining,
Sprint Plan
Stakeholders Role Sprint Review
Total Work Remaining Work Product Sprint Review, Daily Scrum
Work Unit Work Product Sprint Backlog, Development Work
19
SCRUM TO ESSENCE KERNEL MAPPING 21
Scrum
Product Backlog
Product Backlog Item
Sprint Backlog
Scrum Team
Development Work Plan
Work Unit
Increment
Total Work Remaining
Improvement Plan
Requirements
Software System
Work
Team
Way of Working
Sprint Goal
Definition of Done
Opportunity
Product Backlog Refinement
Sprint Review
Sprint Planning
Daily Scrum
Sprint Retrospective
Ensure Stakeholder Satisfaction
Understand the Requirements
Coordinate the Activity
Support the Team
Track Progress
Product Backlog Creation
Development Work Implement the System
Test the System
Shape the System
Understand Stakeholder Needs
Explore Possibilities
COMPOSITE CONSTRUCTS IN SCRUM 22
Sprint Review
Sprint Planning
Daily Scrum
Sprint Retrospective
Sprint Plan
Product Backlog Item
Sprint Backlog
Development Work Plan Work Unit
Sprint Goal
produces
provides input to
may change
Sprint Increment
Scrum Event
Development Work
Produces
Conducts
Product Owner
Development Team
Scrum Master
Manages Product Backlog
Creates
Performs
Ensures enactment of Scrum
Scrum Team
WORK PRODUCT TO ALPHA STATE MAPPING 23
Work Product Alpha Alpha State
Begin In Target
Product Backlog Requirements Bounded Acceptable
Opportunity Solution Needed Viable
Sprint Goal Requirements Bounded Coherent
Sprint Backlog Requirements Coherent Acceptable
Definition of Done Requirements Acceptable Fulfilled
Development Work Plan Work Initiated Prepared
Increment Software System Architecture Selected Ready
Work Prepared Concluded
Total Work Remaining Work Started Under Control
Scrum Team Team Seeded Performing
Improvement Plan Way of Working Foundation Established Working Well
WORK PRODUCT TO ALPHA STATE MAPPING 24
Product Backlog Sprint
Goal
Sprint
Backlog
Definition
of Done
Dev Work
Plan
Increment
Increment
Scrum
Team
Improve
Plan
TWR
WORK PRODUCT DEFINITION CARD 25
Scrum Practice
Product Backlog Item
Sprint Backlog
Development Work Plan
Work Unit
Requirements
Coherent
Acceptable
The stakeholders accept that the requirements describe an acceptable solution. The rate of change to the agreed requirements is relatively low and under control. The value provided by implementing the requirements is clear. The parts of the opportunity satisfied by the requirements are clear. The requirements are testable.
Work
Initiated
Prepared
Commitment is made. Cost and effort of the work are estimated. Resource availability is understood. Governance policies and procedures are clear. Risk exposure is understood. Acceptance criteria are defined and agreed with client. The work is broken down sufficiently for productive work to start. Tasks have been identified and prioritized by the team and stakeholders. A credible plan is in place. Funding to start the work is in place. The team or at least some of the team members are ready to start the work. Integration and delivery points are defined.
Sprint Planning Understand the Requirements
Coordinate the Activity
Understand Stakeholder Needs
ACTIVITY TO ALPHA STATE MAPPING 26
Activity
Alpha States
Activity Spaces
Opportunity Requirement Software System Team Work Way of Working
Iden
tifi
ed
So
luti
on
N
eed
ed
V
alu
e
Est
ab
lish
ed
Via
ble
Ad
dre
ssed
Ben
efi
t A
ccru
ed
Co
nceiv
ed
Bo
un
ded
Co
here
nt
Accep
tab
le
Ad
dre
ssed
Fu
lfille
d
Arc
hit
ectu
re
Sele
cte
d
Dem
on
st-
rab
le
Usa
ble
Read
y
Op
era
tio
nal
Reti
red
Seed
ed
Fo
rmed
Co
llab
o-
rati
ng
Perf
orm
ing
Ad
jou
rned
Init
iate
d
Pre
pare
d
Sta
rted
Un
der
Co
ntr
ol
Co
nclu
ded
Clo
sed
Pri
ncip
les
Est
ab
lish
ed
F
ou
nd
ati
on
E
stab
lish
ed
In U
se
In P
lace
Wo
rkin
g
Well
Reti
red
Product
Backlog
Creation
Explore Possibilities
Understand Reqts
Product
Backlog
Refinement
Understand St. Needs
Understand Reqts
Sprint
Planning
Understand St. Needs
Understand Reqts
Coordinate Activity
Development
Work
Shape the System
Implement / Test
Daily Scrum Track Progress
Sprint
Review
Ensure St. Satisfaction
Track Progress
Sprint Retro. Support the Team
ACTIVITY DEFINITION CARD 27
Scrum Practice
Opportunity
Viable
Addressed
A usable system that demonstrably addresses the opportunity is available. The stakeholders agree that the available solution is worth deploying. The stakeholders are satisfied that the solution produced addresses the opportunity.
Work
Under Control
Concluded
All outstanding tasks are administrative housekeeping or related to preparing the next piece of work. Work results have been achieved. The stakeholders have accepted the resulting software system.
Sprint Review
Ensure Stakeholder Satisfaction
Track Progress Product Owner Development Team Scrum Master Stakeholder
Product Backlog
Sprint Backlog Increment
Sprint Goal
METHOD COMPOSITION 29
Scrum
Product Backlog Refinement
Sprint Review
Sprint Planning
Daily Scrum
Sprint Retrospective
Ensure Stakeholder Satisfaction
Understand the Requirements
Coordinate the Activity
Support the Team
Track Progress
Product Backlog
Product Backlog
Item
Sprint Backlog
Scrum Team
Development Work Plan
Work Unit
Increment
Total Work Remaining
Improvement Plan
Requirements
Software System
Work
Team
Way of Working
Product Backlog Creation
Sprint Goal
Development Work Implement the System
Test the System
Shape the System Definition of
Done
Opportunity Understand
Stakeholder Needs
Explore Possibilities Stakeholder
Business Requirements
Agile Modeling
Opportunity
Software Requirement Model
Software Architecture
Business Analysis
Model Storming
Spike
METHOD COMPOSITION 30
Kernel elements additionally covered by Agile Modeling
Kernel elements covered by Scrum
Add XP
Add
Dev
Ops
Add
SPM
CONCLUSION
You can use Essence kernel to:
Describe practices
Merge them into a project method
Monitor health and progress of the project
Adaptively determine project goals and activities based on
the current state assessment.
31 We’d better
learn and
use Essence.
I think so, too. It
really makes
defining and using
methods easy.