Five steps to a feature lifecycle

Agile teams typically track closely the status of team backlog items. We need to know whether they are waiting to start, in progress or completed.  These three states allow us to run the basics of planning and tracking, often representing these on a Kanban board.

• Waiting items show us how much work we have ahead in the backlog. Remember that backlog is our “fuel” so we need to ensure there is always enough prioritised work to keep the team busy.
• In progress items are our current focus. We focus on closing these out (“Look Right”) and manage Work in Progress levels to keep the team focussed.
• Done items show us what we have available to deliver, given a robust Definition of Done. Tracking these allows us to use Velocity to track progress

Further subdivision of team backlog item states will vary by organisation.

• “Waiting” could be subdivided into “Ready” (passing the Definition of Ready) and “Not Ready” (needing further Backlog Refinement).
• “In Progress” is often subdivided into Software Development Lifecycle (SDLC) stages, although with care, as this risks giving the impression that these (especially coding and testing) are sequential rather than parallel.
• “Done” should not be subdivided according to the principle of the “Definition of Done” that the backlog item is complete and deliverable when declared “Done”.

Feature lifecycle

As we have seen elsewhere, our value streams are represented as a roadmap similar to a task backlog, but consisting of Features. We need to communicate what state the Feature sits in.  If we want to visualise a roadmap, we will typically select a set of features being considered for the next release. We will then show which features are waiting, in progress or complete.  This will build a visual picture towards the goal for the timebox or release.

This means we need to define a lifecycle for Features in a similar way to how we define these stages for backlog items.  The maturity state of a Feature is valuable organizational language.  It sets expectations about what we expect from a Feature at different stages, in a similar way to a Definition of Done.  If a Feature is still an idea and doesn’t yet have a firm definition, we cannot expect a schedule for when it will be delivered.

The lifecycle of a feature will depend on the domain in which you operate.  In some organizations, stages will already be clearly defined.  There may be an accepted language for these stages.  This is especially true of highly regulated industries where the state of the work will have significant, probably legally-enforced, implications.  For example, the diagram below could be a simple model for a medical device.

Discover -> Develop -> Pre-clinical -> Clinical -> Launch

In general at a feature level organisations are free to define their own feature lifecycle. Part of the process mapping of how work flows through the organization is to understand the language used for features.  A typical software development feature lifecycle might be as below.

Definition -> Investigation -> Development -> Delivery -> Close

The actual names, of course, may vary between organizations.  You will need to decide these for your business.  Most importantly ensure that everyone understands what happens in each stage.

I am focussing here on the lifecycle during development. The full product lifecycle needs to address the end of life or retirement of a feature, but this is not being considered here.

Definition

This phase is focussed on ensuring that the objectives of the feature are understood.  The definition stage is the handover from the business stakeholders.  The feature needs to be on a firm foundation with everyone involved agreed what constitutes “success”.  Features are far more likely to succeed without the conflict inherent from different stakeholders having different ideas of what the desired outcome may be.  This stage ends when the requirements and acceptance tests for the feature are adequately understood that it could be created.

Investigation

The “definition” stage agrees what the problem is which we are trying to solve.  In this stage we move on to agreeing on the solution.  This will generally involve the development teams.  There will be some initial design work. 

Remember that a Feature is typically significantly larger than a single backlog item.  There will typically also be some level of initial breakdown and planning to create a set of items on a backlog.  This represents what needs to be done to create the feature.  Probably there will also be some Spikes generated on the backlog to address this work. 

Development

This phase is the creation of the feature.  The work will be on the team backlog(s).  Using the various techniques described in the Plays, the teams will generate the deliverables.  This may involve a significant level of learning and change.  This phase continues until the acceptance tests are satisfied and the feature is complete and ready to be delivered

Delivery

The feature now needs to be deployed.  How complex this may be depends on circumstances.  In the medical example above, deployment is complex and regulated.  Delivery could be an extensive process before the product is ready for the market.  In a SaaS software system, it may simply involve pushing code to a deployed system with a single keypress.  Most environments will be somewhere in between.

Close

The feature is now completed and delivered. As mentioned above, this is not the end of the product lifecycle, and feature retirement needs to be considered, but when aligning backlog and Features, we can generally consider only up to the Close point.

Aligning lifecycles

One area which can be challenging is to keep the lifecycle of the Feature aligned with the lifecycle of the backlog items. We need consistent communication but these data sets are typically managed by different people. Alignment across all the data is key. Remember that we deliver Features by delivering the backlog items such as Stories which we associate with the Feature. At any point we will have a mix of backlog items at different states.

Imagine we gave a Feature which is broken down into ten Stories. Two of these Stories are complete, one is In Progress and the remaining seven are yet to be started. In what state is the Feature? This may sound a trivial question, but it is an important area to ensure consistency.

The answer is “it depends” but that the organisation needs a consistent approach. Remember that the state of a Feature is a tool for communicating around the organisation. If there are backlog items completed, the Feature has probably moved out of Definition stage. But are the completed backlog items investigative Spikes? If so it is probably in the Investigation stage. If they are implementation work the Feature is more likely to be in the Development stage.

Remember that a roadmap and the contained Features are a tool to help the organisation prioritise and communicate internally and externally. The team, and especially the Product Owner, is best placed to decide at what point the Feature transitions between states. The team can use this to communicate the level of understanding and confidence in the Feature. It is important however that the reporting is consistent across Features.

Checklists in the feature lifecycle

Checklists are a very powerful tool at the backlog item level. They allow us to check that the key quality points have been considered.  As an example they might be used to implement a “Definition of Done”. Most importantly checklists protect busy people from making simple errors.

Checklists are also very powerful with the value stream flow.  I have found implementing checklists with features to be a very effective technique.  Checklists can be implemented at each of the stage transitions for features.  In general, there are far more people involved in the decision process for value stream items than for backlog items.  More people involved means more opportunity for something to be missed.

Checklists are a great tool to protect against these errors.  Typically I have found the feature checklists are mostly about communication and collaboration.  They can help ensure that the right opinions have been sought and that there is general agreement when communicating the state of features.

It is common to misconceive how checklists function in complex lines of work. They are quick and simple tools aimed to buttress the skills of expert professionals.

“The Checklist Manifesto” – Atul Gawande

Good practices

Once you are implementing value streams and representing a roadmap, consider the implementation of a feature lifecycle. The key requirement is to agree around the organisation the language which will be used. What will the states be called and what are the conditions for transition between states?

Review how the teams are using this to ensure that they keep the feature state as an effective language tool around the organisation. Review also the understanding of reports to ensure that the data are being read as intended.

Investigate using checklists as a tool to manage the feature lifecycle. You may already be using checklosts for backlog items, and Definition of Done is a good place to start. E’xtending to Features can add significant value.