Sharing IT Best Practices with youSharing IT Best Practices with youThis article describes how to define features and stories.
A feature is a description of a piece of functionality that should not cost more than half of a DevOps cycle time. A feature is described in requirements of the business terms. Features are the epic building blocks and are differentiated in stories.
A story is a technical description of an object to be realized or the configuration of an object. A story is comparable to a Request for Change (RFC).
A data model is a description of information that needs to be administered. For example, features and stories. Important to a data model is what data elements are available in a data object. The relationship between objects is also described.
This concept indicates that in the deployment there are pipeline tools that cannot be used optimal because in the past too few meta data have been provided to the objects which are used in the tools. For example, a test robot cannot select test cases for a regression test if it is not clear which test case belongs to the set of features and requirements that have not been changed.
To enable proper administration of DevOps objects such as features and stories, it is important to get the information needs of these objects from the users. Then, these objects must be modelled and provided with relationships. This article describes for two objects (features and stories) the attributes and relationships between these objects and other objects.
An important aspect of the DevOps approach is the deployment pipeline. To give this pipeline maximum throughput, many tools need to work together. The collaboration of tools depends on the extent to which the tools provide the right information, apart from the connectivity of the tools. Therefore, mapping the information needs of the stakeholders of the DevOps process is very important. A second aspect related to this is information debt.
The following list of attributes gives an impression of what to include in the administration of a feature
Feature ID: A Feature ID is important because there are many objects related to a feature. For example, the feature ID is included in a requirement, a story and a FAT test case include the feature ID.
Epic ID: If a feature originates from a question by the user, then there may be not a parent Epic. But in the realization of a product or service there is a parent theme and epic. This field describes this relationship.
Applicant ID: The requestor of a feature must be informed about the status of a feature. This means that a feature is linked to an ID such as an Active Directory ID. This implies that the tool in which the features are described must also have a LDAP connection.
Application Date: The date the feature was requested is important because a maximum response time and realization time may have been agreed in a SLA.
Priority: The priority of a feature is determined based on the business value and effort required to realize a feature. The business value is determined by the product owner and the effort by the DevOps team.
Story Points: These are the units in which the DevOps team indicates the effort to realize the feature. Usually, the Fibonacci range is used. An alternative are the Ideal hours. It is important to base the story point on the sum of the story point of the stories that is consisting in the feature. This gives a more reliable picture than an estimate of the abstract feature.
Desired Release Train: A feature only lasts when all the underlying stories are realized. The user who requests a feature or indicates the release planning often gives an indication when the feature must be finished. The date on which the last story is going live should therefore be before this date.
Determined release train: The train with which the last story of a feature goes live is the determined release train. The functionality is released to the user. This date is important for determining the cause of the escaped defects.
Related CI application: A feature is essentially nothing more than a change request. The implementation of that feature must therefore be administered. Therefore, the Feature has been linked to a CI that identifies the application in which the feature is realized.
Related CI service: In addition to linking to an application, a link with a service is needed to scope the feature.
User Story One Liner: A feature is described in the format of a user story. This attribute contains this user story.
Status: The status describes the position of the feature in the DevOps process flow. It is important to define a workflow for the status. A status mutation must also be restricted to a particular role with these rights. This is important from an audit perspective.
Audit trail: It is important that the tool provides an audit trail, ie, who has created, mutated and deleted (logical) a feature, as well as the adjusted attributes (old and new values).
The following list of attributes gives an impression of what to involve in a story’s administration
Feature ID: This is the feature for which the story is executed.
Domain: This is the domain that executes the story. This is for example an information domain (functional management), application domain or infrastructure domain. A story belongs to only one domain.
DevOps team: One story is only executed by one DevOps team.
Change authority: There are several possibilities for the decision making of a story. Examples are the DevOps team themselves, the product owner, a change manager, or the Change Advisory Board or on the other.
Baseline: A story is a change to an object (information, application or infrastructure). The source files in which the changes are defined belongs to only one baseline.
Risk control: The control of the identified risks can be realized through various types such as a change management, a default change, an RFC, the passing through the DTAP street and other controls.
Story points: The extent of the story needs to be determined fixed so that the sum of the stories can be used to determine the extent of the feature and thus the priority (in combination with business value).
Status: The story status describes where in the DevOps process flow a story is situated. It is important to keep a status of workflow. A status mutation must also be assigned to a particular role with these rights. This is important from an audit perspective.
Audit trail: It is important that the tool provides an audit trail, ie, who has created, mutated and deleted (logical) story, as well as the adjusted attributes (old and new values).
The relationship between a feature and a story is a 1:n relationship.
Discuss with us about this article on LinkedIn.
DevOps Best Practices, ISBN: 9789492618078
Agile Service Management with Scrum, ISBN: 9789071501807
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.