It totally depends on the team and work. We apply Scrum or Kanban separately. For example Ops team almost exclusively executes Kanban method, yet Dev teams prob

It totally depends on the team and work. We apply Scrum or Kanban separately. For example Ops team almost exclusively executes Kanban method, yet Dev teams probably use Scrum. For the columns on Jira: we have 4 - 5 columns; Backlog - To Do - In Progress - Blocked - Testing(sometimes) - Done. I do believe this is more than plenty, although in some customers I have consulted to might have ~10 columns which some of them reads like code review, test on staging, test on prod. Ticket scoping is the most important thing if you want to execute a Kanban/Scrum method. It shouldn't be too broad (i.e. fix all the bugs) or it shouldn't be too focused (i.e. write tests for this function). Each story/ticket must be an independent deployable feature or function written with a business level understanding with clear acceptance criteria. Clear acceptance criteria in bullet point form is very important! (repeated for emphasis) Backlog is prioritized by business value and urgency, and transferred to the To Do column by a business/product owner or a PM to make sure no one is ticket-starved. Depending on your work or infrastructure capability, you can release each ticket as a separate deployment or you can create weekly or bi-weekly release packages that are well tested on a staging environment. Any code change that has stayed unreleased more than 2 weeks probably needs a fresh look.