How to set up Kanban in Jira for development of your own products on Meetville example

wrote this on Авг 12, 2015

Software for Startups, Education for Startups

In this note I will tell you what final development process in Jira we’ve come to. I also briefly describe the way we’ve made till the present day. A reader will get ready-made regulations with process description and development rules. Take them and introduce them!

Beginning

We started from an ordinary issues list and filtration with the help of JQL. We used priority field in order to make priorities. We could divide tasks into 5 groups (trivial, minor, major, critical, blocker). We also used Agile plugin Jira Agile (it was called Green Hopper earlier). We solved tasks in a random order. For example, we had 10 tasks with major priority and a developer took any task with this priority after finishing all tasks with a higher priority. We worked in sprints at that moment so the order wasn’t important. But a result was important, i.e. features accepted by testers and released to production.

Drawbacks

But the process has some disadvantages. These are the main ones:

testers checked a feature not when a developer finished it but some time later. A developer had already forgotten it and spend a lot of time on plunging into the task again. Now in Kanban, a tester checks a feature right after a developer has created it.
features were released to production only at the end of a sprint, once a month/month and a half. We release them almost at once after a tester accepts it now.
a feature code got to master with a big delay. As a result, we had to deal with many conflicts. A code gets to master almost after it’s accepted by a tester now (rather quick).
it was difficult to understand what a developer was doing at the moment. We had to ask them all the time “What are you doing?” and tell them what to do next.
it’s not clear who had tasks to do and who was free.
developers didn’t know what their colleagues were doing.
a developer could do several tasks simultaneously which resulted in expenditures on context changing.
we wasted much time on evaluating features before a sprint start. We don’t need to evaluate them now.
urgent tasks on fixing bugs or enhancing features on production made us miss sprint deadlines and as a consequence we had some negativity from inner clients.

Kanban is a savior

I decided to try Kanban methodology once (it was added to Jira Agile plugin or it was called Green Hopper earlier). Surprisingly, but a team’s capacity increased significantly in a short period of time. We started to release more features during the same time period. Everybody was satisfied: users got the most useful features faster, inner clients weren’t upset because of missed deadlines anymore and we saw the increased speed of software development.

If you know nothing about Kanban methodology, I recommend that you read this article.

Advantages

Here are the pros we’ve got after introducing Kanban:

we saw narrow places at once. Many tasks were stored in Testing column. Our tester didn’t cope with checking tasks. As a result, our developers completely forgot the tasks a tester re-opened in a week or two. If they forgot it, it means they need to look at a code and remember what it was about. A solution is to get another tester!
a product manager started to manage the order of feature release more pointwise. An order is very important in this chaotic world. A task on making priorities is one of the most important things for a manager in Kanban. Requirements, just as reality, change constantly. Some tasks after being in a queue for some time lose their significance and go to the bottom where nobody will see them. Some tasks. vice versa, go to the top. ?'est la vie.
we started to do what really added value to our product. We managed to hide tons of useless bugs from our developers. Testers are awesome, they find bugs, but bugs differ. And to distinguish bugs is a task for a person who can and takes into consideration both product users’ and business interests. It’s a work for a product manager.
developers stopped wasting their energy on choosing next task — “Should I work on this task or this bug?” It was even more difficult if they both had the same priority. Developers can spend this energy on business logics and programming now. And reading reddit news.
we can see a full picture now. You can open a desk and see what everybody is doing, what’s already done. It’s easier to see big things from a distance.
we’ve become more flexible. we started changing requirements on the go without any opposition from developers. Developers didn’t want to do other tasks earlier because they were afraid of missing deadlines on a sprint. A developer works as a processor with Kanban — by bits. One bit — one task. Just don’t hinder him/her in a process. The more frequent are bits, the more flexible is a development team. An ideal bit for our team is 8 hours.

Process regulation

I will show you our structure and the rules we observe in our team. It’s a ready process regulation. Take it and introduce into your product.

Here’s the main and only illustration— our structure in Jira.

Jira structure in Meetville

Vertical task priority

Tasks are divided into 3 levels:

1) Blockers — are the first to be done.

2) Tasks and Bugs — are done when there are no tasks in Blockers group.

3) Someday — are done when there are no tasks in Blockers and Tasks and Bugs groups. It means never.

Rules:

a manager assigns priority and order to all tasks.
if doing tasks from Tasks and Bugs or Someday groups tasks in Blockers group appear, a developer indicated the time when he/she will take a task. A manager answers the comment. If the answer is positive, a developer starts doing the task as agreed, if no, a developer starts doing the task immediately. If there’s no answer from a manager, a developer acts as if it was a positive answer. It’s also possible to discuss this question in a face-to-face conversation with a project manager.
a developer mustn’t do any task with a low priority until all tasks with a higher priority are solved.
tasks are done according to their order inside a level (from top to bottom).
a developer mustn’t change task priorities.

Horizontal task movement

A team does all tasks and goes through all columns from left to right.

To Do

tasks for developers with Jira open status are stored here.
a developer has to take the top task (if there are no tasks in Reopened column) and assign In progress status to it, i.e. move it to the corresponding column.
a product manager watched the process of task fulfillment, their order in To Do column and their priorities.
if a developer assigns a task to another developer, a task essence and an executor should be agreed with a product manager.

In Progress

there are tasks with Jira in progress status in this column.
if a developer has no tasks in this column, it’s considered a layup.
a developer should have only one task in this column.
the maximum number of tasks in this column should equal the number of developers. If the number has increased the maximum, the column becomes red which signifies a process violation.
a developer should check whether he/she has opened several tasks at once. If yes, a developer should leave only one task.
if a developer has finished a task, he/she must release it for testing on an attached dev-server and assign Resolved status to it, i.e. move it to Testing column.

In Testing

tasks have Resolved Jira status here and are tested on a dev-server.
testers work with tasks from this column till 2 p.m., if there’s no special testing order with a product manager. Then testers work on Deployed column.
if a task is successfully tested, a Closed Jira status is assigned to it, i.e. the task is moved to Ready 4 deployment column.
if a task didn’t pass a test, a Reopened status is assigned to it, i.e. the task is moved to Reopened column.
if there’s a task in this column which was assigned to a developer by another developer, the one who created it should check it according to the above-mentioned points.
if there’s a sub-task relating to a bigger task in this column, a product manager should hide it from a board (we hide them by placing Fake version in Fix Version field, the version has been already releases, do it disappears from the board) and testers will check the task as a part of a bigger task.

Reopened

tasks with Reopened Jira status that need to be fixed are here.
a developer mustn’t take a task from To Do column, if there are tasks in this column.

Ready 4 Deployment

there are tasks with Close Jira status here that demand release to production or tasks that will be included into the final build and published to AppStore/Google Play.

Deployed

there are tasks with Deployed Jira status here and the ones already released to production or included into a mobile app build sent to a store review.
a product manager should include tasks concerning mobile apps into road map .? Apps Versions for a further version control and then to hide them from the board marking them as Fake version.
a product manager should also actualize task condition on Production board in Trello, i.e. move solved tasks from Developing to Live. All interested people get a notification about a new feature release.
tasks that aren’t connected with mobile apps must be accepted by testing department in production.
if testers took a task, Accepted Jira status is assigned to it.
testers work with the column after 2 p.m., if there’s no special order agreed with product manager.
technical tasks created by developers must be accepted by authors and Accepted status should be

Accepted

there are tasks with Accepted Jira status here. Testers assign the status after checking a task in production.
a product manager hides tasks ( Fake version) from this column from time to time.

About the Author

Leonid Zverugo is the CEO of 32dayz (task and time tracking).