Mixing release support and new development

The first thing that comes to one’s mind is “don’t do it!” And frankly, it’s far from best practice.

But my recent project experience is exactly the opposite. With known-not-confirmed feature requests for the next version from the client, our dev team was split into two, because:

  1. the initial release had just occurred, and we had a variety of technical debt mounted.
  2. we needed to estimate roughly how long it would take for us to vertically implement the next release.

In not exactly in the below order, what are the steps we usually go through?

release operation check

pop support requests to fix

resolve issues

qa the fix

release or reopen

discuss new features

estimate roughly, in vertical epics

find ways to componentise at epic level (emergent architecture)

link data-flows between components

define interfaces

prototype interface integrations

work on positive workflows using automated/manual tests

slice epics into stories

resolve any interface or dataflow feature discrepancies

find ways to not reinvent complex wheels

implement as quickly as possible

plan load testing

acceptance testing

risk identify & plan

release and support