The Train-Inferno Development Cycle

# The Train-Inferno Development Cycle

The continual release focused development cycle.

# Sprints

In the Inferno development cycle the team sets the length of a sprint, this defines how often each train departs. The train is a new version of a product.
For each sprint, the team must decide the tasks they wish to tackle and must process the task category, stage and a fare.

The code for each unit of work will be released on the next train when it has achieved it’s fare.

 ## Categories

 - Features

Features by definition are epics - they implement a new piece of functionality. Each feature has to be broken down into a series of enhancements.
A feature can only be shipped once all of it’s enhancements have been achieved.

 - Bugs

A bug is a deviation from the desired behaviour or experience. Bugs that fit into the current stage of a feature must be addressed immediately, once in a higher scale don’t need to be addressed as urgently but every effort should be done to do a regular clean up of these.

- Spike / Research

Spikes and research tasks are pieces of work where we find out information for implementing a feature, usually this results in work being thrown away once the information is acquired, so we can then turn it into a series of enhancements.

 - Enhancement

An enhancement is a intended deviation from the original behaviour to improve the experience of the product or work towards implementing a feature. Only enhancements from the current stage of a feature may be implemented.

 ## Stages

Stages are how we categorise bugs, enhancements and features. We focus primarily on the stage we are on.

- Specification

 For features / enhancements, this is where we specify what it is we exactly need to do. All work starts in this stage, the aim is to break features into enhancements and spikes/research for the other stages. Ideally the lowest staged tasks with the lowest fares are identified as quickly as possible to promote async development.

For bugs this is the stage of confirming the users issues, the core specification of the issue.

 - MVP

The MVP is the core experience, for features and enhancements this is the minimum we need to achieve for the 80% of Use Cases.
For bugs this is the easiest fix which solves 80% of cases.

 - Painpoints

Once a feature is released or bug fixed, this is the stage where we can apply our learnings and implement additional functionality / fixes to resolve pinpoints we have identified i.e (“A user finds it annoying to have to invite friends one by one”)

You may have to revisit this page through a course of a product and in some cases go back to the MVP if the core premise is wrong. 

 - Scale

Once you have got a good MVP and have identifier most major Pain points, the next phase is scaling.  This is where we try to fix the remaining 20% of use cases for features and bugs. 

 - Special Bonus

Some tasks additionally belong in the Special Bonus stage, unlike other stages, tasks in this stage can be done earlier if desired but tasks cannot be done before the tasks the highest stage we are currently targeting for a given feature. Any task belonging in this stage should be treated as being the lowest priority.

## Fare

The fare is the price a unit of work has to pay to board a train. This is the“Definition of Done”, nothing can board without achieving this. Ideally as part of specifying this fare we should try to lockdown a time-frame or points for each piece of work.