Increased MRR by 12,54%

Just buy decreasing the number of context changes for developers

During October, 2019, developers were working on mainly on refactoring a complete product portfolio element. Everything was planned beforehand and the PO could effectively lead the implementation.

USD values were hidden (as it is company secret)


This refactoring took a long time. We added 3–4 bug fixes to each scrum sprints.

But customer satisfaction started to decrease as the issues they faced were delivered much later than they expected it. Just too many bugs were reported but the resource we dedicated to solving these issues were not enough to fix them fast enough. It even caused higher level of churn.

On top of that, developers couldn’t solve these issues on time. Bugfix estimations were usually bad (due to unexpected root causes) and switching context between fixing bugs and refactoring wasn’t productive.

Basically, the short-term bugfixes were hindered by the longer-term project.


When I realized this problem, I proposed a solution to this:

Add another Jira board, that isn’t scrum but works in Kanban methodology. In addition, dedicate 1 regular person who works only on this.
I expected:

  • It minimize the number of context changes which improves productivity
  • So the time-to-close for bug- and hotfixes will decrease
  • Therefore, customer satisfaction increases


It not only stopped churn, but by focusing more on bugfixes, the MRR increased by 12.54% in from January to March, because customer satisfaction radically improved.

  • Kanban is “less documented”: therefore, fixes happened faster and customers’ problems were solved faster
  • Estimations were not for a 2 week sprint but for 1 bug: it increased precision and lowered the cost of turning back
  • Working limit for Kanban columns also increased productivity

Software Product Manager at Automizy.