Best practices using versions in Kanban

Lars Böhnke_hii2xh

Hey there! I was wondering what are best practices using versions with Kanban. We are running a small online platform using Kanban and continues deployment. This is a really broad question but I'm struggling to come up with a good solution...

We deploy small fixes and improvements directly.

We deploy big features and improves first to test, then to prod.

Additional question: how do you deal with the fact, that versions from a parent issue is not inherited to the sub-issue? That behaviour make look some version like 50% of work done, 50% left - but only because the sub-issues are missing. And adding manually the version to each sub-issue is really not convenient.

Joey_Spooner

Hi Lars!

Are you using versions for the small fixes in addition to the big features and improvements?

I think you'll have to decide how you'll want to use the reporting to inform you with respect to releases. As an example, how many releases did you have last week that were fixes (failure demand) versus new features (value demand)?

I've used them to handle big features, but with small fixes, there isn't time to draft a version, so I usually "release" those fixes at the end of the day or week using a timestamp as the version. It's not pretty, but works great for fast moving teams.

I would highly recommend using Triggers where possible to automate some of your flow, but there's also Automation for Jira. This way you could automatically version the smaller fixes quickly and keep track of them. You can do this with Triggers or Automation. I'd recommend you do it using the Issue Type to set off the Trigger or Automation.

I don't use sub-issues to track valuable work. I usually use the default issue types in Jira or create my own. This way, it tracks well with releases. I'm using the cloud version.

-Joey