Each software development company and development team knows Jira and uses the main Agile principles in the development and project managing system. But there are a few methods to use it, called Scrum and Kanban. Here, we will talk about both of them to clarify their meaning and help you understand which one can better handle exactly your development processes.
Scrum is the method of organizing product development that divides it into fixed time intervals, called Sprints. A Sprint can take two or four weeks and aims at the product or its specific part. Therefore, Sprint tasks are carefully planned and divided between team members. During the Sprint, there are daily standups where each team member talks about tasks they accomplished yesterday and are going to accomplish today. Regular team rallies depending on the needs of team members and the project's needs. A demo session to discuss the list of tasks already done and outline the remaining ones. Retrospective assessment of sprint completion.
The most common scenario is when tasks are planned for a two-week sprint. Here is one of the recommended ways to plan a two-week sprint, but of course, there could be a difference depending on your workflow and project. So, during the first seven days team works on the tasks set, on the eighth day, there is a demo session to discuss the complete tasks and remaining ones. On the ninth day, the next Sprint is planned, in which new tasks are outlined, and those that were not completed in the previous Sprint are carried over. On the tenth day, there is a retrospective of the Sprint, and the Sprint is finished.
Also, in Scrum, there are three specific roles that members have. The product owner represents the interests of the customer. The Scrum Master ensures that the principles of Agile and the Scrum methodology are followed. And employees plan and execute tasks. The role of Scrum Master is often assumed by project managers, who receive requirements from the customer and bring them to the team.
The key indicator is how much time it takes to complete the tasks. This is done when planning a Sprint with all team members. Of course, the customer can require the task to be completed within a specific timeframe, and the tasks can be calculated more accurately. There are a few difficulty estimation systems for this, one of which is Story points. It shows the amount of work done in the Sprint. Also, it shows how much the team can complete in a certain amount of time and calculate the completion of work and the frequency of product release within a clear timeframe. You can also conclude that it tries to keep minimum changes to sprints and make all work processes transparent and predictable.
Assessment complexity is one of the most challenging tasks facing the development team. After all, when the customer sets the tasks, allowing for all possible changes and updates, he still does not know all the internal aspects of development that affect its complexity and duration.
For this purpose, tasks are divided into smaller tasks. Which helps customers prioritize and focus on all work areas as accurately as possible. And the team gets the whole possible picture of the upcoming work and the opportunity to give it the most accurate assessment. It is necessary to involve each member of the team to assess each task (developers, designers, testers, etc.), who will tell exactly how much time tasks may take depending on its complexity, volume, possible unpredictable problems, or adjustments, dependence on other tasks, and so on.
To create your Scrum board in Jira, you need to click Create Board on the left side menu. You will be prompted to make a new project and a new board, a Board from an existing project, or a Board from an existing JQL filter. We will choose the first one because those who have access to the other two options have already made boards, and the different options include the same steps but fewer of them.
After that, you need to name the board, the project and choose the project lead. After entering all that you need to select Simplified Agile Workflow or Jira Default Workflow, we choose the first one. Of course, you can modify your workflow after this, add more columns or change their names, add filters depending on your project, etc.
To get started, you need to create a Backlog, list the necessary product requirements, and prioritize tasks developers need to complete to make the product. These requirements can be in Epics or Stories, which will be added to the Sprints. It doesn't sound elementary, but it isn't.
Click on Create Epic on the left bar, where you will get the option to bind this to a specific project, select the type of Epic, and name it. For example, call it 'Rewrite an online store search filter.' Make a few of the Epics with some goals for each, and you will see them on the Backlog list.
Now you can make Sprints into which you will add your previously created Epics. At the top, click Create Sprint and name it. After that, drag and drop the Epics you want into it. Then click Start Sprint, specify the Start and end date, and click Start.
This Sprint is now started, and its Epics are on your Scrum Board. Initially, you only have three columns. To-Do, which contains the Epics now, In Progress and Done, to which the Epics will move as they progress.
Kanban is the method of organizing software development continuously and flexibly. Kanban also uses columns that show what stage the task is in. But there are no fixed time intervals or roles.
Instead of Sprints, there is a WIP (Work in Progress) system to organize the tasks. Its meaning is that each column can only contain a certain number of task cards, which forces the team to complete the tasks as quickly as possible, rather than calculating the time to achieve them. Also, it makes downtime self-regulation possible. You can't fail to complete the tasks you want because it prevents others from being completed. Kanban tends to have far fewer meetings to plan and grade the work done, and the product can be released as it is ready without assuming specific deadlines.
Kanban is an excellent choice for long-term projects that have been running for a long time and are going to run along, and each team member knows a project perfectly and knows their responsibilities.
Creating a board is almost the same as in the previous case. Click Create Board, but this time choose Kanban type. Then also choose to Create New Board and New Project and name them. Next, you will also have to fill Backlog, but this time without Sprints. After that, you already have the standard To Do, In Progress, and Done columns on your new board.
And inside those are also Epics, which you move around depending on their completion stage. Also, the cards that these Epics are on have different statuses. You can further customize this in the board settings, such as adding columns, renaming, adding statuses, etc.
Yes, you don't have Sprints, but you are spurred on by the fact that the columns don't contain an infinite number of cards, and if you run any of the development stages, all tasks will stop until you complete the blocking tasks.
All in all, there is no universal key to managing anything. These are just two different methods of organizing development. Depending on what the customer wants or your product, one method may do more good than the other. You can work on any project in any style with an equal case.
The main feature in Scrum is that you have Sprints, which determine the order and limitations of tasks. You have the tools to plan and evaluate tasks carefully. If you are making a product from scratch and it requires a lot of tasks within a specific time frame, or train a team on a project or let the customer be a direct member in the development, then maybe Scrum will suit you better. For example, if your customer or product requires releasing regular updates at the end of each month.
The main feature in Kanban is that you limit the number of tasks in a column, which also creates order and contains in the execution of tasks. It also doesn't require as much careful planning and allows you to add the tasks more flexibility, and allows for more self-organization. If you are working on very different parts of the product simultaneously with other priorities and often have to consider new factors in development, you're probably better suited to Kanban. For example, you assist an existing product, and it requires regular changes and releasing the proper updates when it's ready.
It is worth noting that here we've covered the main principles and talked about the two methods in general. Most development teams around the world use them at the moment. There are also combined methods or author's methods that specify the development of a particular product. But the best thing is that all these methods, despite the vast number of features, have a simple basis calling to simplify development, and it works.
At Mad Devs, we use both methods depending on the situation and make the most of each method. So our customers always know what is going on, what they pay for, and why they can trust and rely on us.
Previously published at maddevs.io/blog.