Contexts

In Nektion, there are three main types of objects to model a hierarchy of different concepts: relation types, item types and contexts.

Item types are types used to represent different items. We could create an item type called Product, for example, which could represent our company’s individual products.

Relation types are used to indicate relations between two or more item types. For example, if for every product, there could be some features planned, we could create a relation type called Product has Feature, where Product is the “parent”, and Feature the “child”.

Contexts are objects used to group together item types and relation types closely connected to each other. A context could be as shown below:

Picture 3: Example of contexts, relation types and items types in a model

In the above picture, Product is hierarchically a top item type. It has a relation type to a Release and to Feature. Furthermore, a Release also has a relation type to Feature, since we want to be able to add Features to an item of type Release. Then there is a relation type from Feature to Story.

We can call our first context for instance Product Context and it consists of the following relation types:

  • Product has Release
  • Product has Feature
  • Release has Feature
  • Feature has Story

It is important that the direction of the relation types is hierarchical from “parent” to “child” and therefore we should not create a relation type like Release has Product. Another way to think about it is that in general the relation type direction goes from one to many, for example, one Product has many Releases, one Release has many Features, and so on.

Note also that there could be multiple relation types between the same item types. For instance, we could have a relation type called Product has wished Feature that is used for Features that someone (e.g. a customer) wishes will be included in the product backlog.

We have a second context with Team as the top item type. We can call it Team Context where we define the following relation types:

  • Team has Story
  • Team has Sprint
  • Sprint has Story

Note that the above model might well have been defined differently. For instance, there is no Team has Feature relation types, so you cannot allocate a Feature directly to a Team. What is the correct choice boils down to how you want your model to work. You can always tinker with it and change it later.

We have one more context that we need to create. In Nektion states are also item types. From our views (see product kanban and sprint board), we have a state model for our Features and Stories. We can group these into a State Context where have the relation types (note the direction from parent to child):

  • Feature State has Feature
  • Story State has Story

Note here again the direction. The parent type is the one that can have multiple of the other, but not the other way around. For example, a Feature has at any given moment one and only one state, but multiple Features can have the same state.