This article will guide you through the Kanban and Scrum processes using the Agile plugin features.
Firstly, let's say a couple of words for the methodologies. Scrum is an agile process that allows us to focus on delivering the business value in the shortest time. Kanban is a visual system for managing software development work. So, Scrum prescribes time-boxed iterations, however, Kanban focuses on planning a different duration for individual iteration.
From Agile 1.5.0, a new feature was added - Board types Scrum and Kanban:
In relation to the mentioned new features, it is recommended that the following guide would be also checked as it reveals the difference between Sprints (Scrum feature) and Versions (Kanban feature) ---> Planning your version and sprints
Below, you could check the steps of using the Agile plugin.
- 1. Setup Agile board
- 2. Create issues - user stories
- 3. Add stories to the backlog and estimate them
- 4. Create a Version (Sprint)
- 5. The Agile board is now divided into Kanban and Scrum
- 6. Organize sprint planning meeting
- 7. Move issues from backlog to Version (Sprint)
- 8. Start the Version (Sprint)
- 9. Complete the Version (Sprint)
- 10. Organize a retrospective meeting
1. Setup Agile board
Details about how to do it can be found here
2. Create issues - user stories
The User story is an issue category (next to task, bug, or support in Redmine), but there is a small difference in how you describe what has to be done. The User story, as the name suggests, is based on user experience. Such an issue shouldn’t be too complex, as it is the smallest unit of work in Agile.
As a user, I want to be able to log in to my account so that I will be able to see my payment history.
The User story is always built the same way. The skeleton of each user story is created by a product owner, and then the whole team adds details.
To add some user stories to your project, you first have to create a Version. Your first version will be Backlog, – which is a list of tasks that have to be completed to deliver a product.
There are two ways to create a version:
- Go to Project → Settings, and click on the Versions tab. You will see a green circle with a “+” sign on it.
- Go to Edit on the issue page, and look for the Target version. There will be versions to choose from and an aforementioned green circle allowing you to create a new version.
After you click on it, you will have to provide some details for the version.
The creation of a Sprint could happen in the same way but in the sprints tab in the project settings.
To be able to save an issue as a user story, go to Project Settings → Issue tracking, and check User story.
Please note that if the "user story" doesn't exist, you have to create it in Administration (on top) → Trackers:
3. Add stories to the backlog and estimate them
When you have some user stories created, assign them to Backlog. You can rank them by dragging and dropping them within the backlog column. It is also very important to estimate how much time each task would take.
In Agile, you estimate a task by giving it an appropriate number of so-called story points, which rate the effort of work needed by using the following scale: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100.
How do you estimate a task? The best solution is to sit together with the team. First, each member estimates the task by themselves, and later the team agrees on a final estimation. At first, Versions (Sprints) might not be estimated 100% correctly, but you will eventually learn how to do it properly. At the end of each iteration, there should be a meeting called Retrospection (or retrospective meeting), where the whole team discusses the last Version (Sprint). This is a great opportunity to incorporate insights (also including estimations) from the previous iteration(s).
In Redmine, you estimate by giving a number of points when creating/editing a user story. Please that note a standard task or bug will not have the story points field available.
4. Create a Version (Sprint)
Version is a time interval during which the team forecasts how long it will take to complete a certain number of user stories. A Version can last from one to four weeks (or one to two months). The team decides the length but starting with two weeks. You should stick to the agreed length, as it helps with estimating and future velocity predictions.
- If you work with subprojects, at least one Version should be in the subproject to be able to use parent project sprints (and sprints at all).
Here come the new features as well - you could use Sprints for some short, time-boxed periods related to the Version.
For details on how to create a version, check step 2.
5. The Agile board is now divided into Kanban and Scrum
As stated at the beginning of the guide, the new functionality of the Agile plugin allows dividing into Kanban and Scrum.
The Kanban board allows the tasks to be viewed in relation to the Versions:
However, the Scrum board shows the tasks that are related to the Sprints. The new thing here is also that there is an option to show the backlog on the Agile board itself:
To facilitate the process, you could directly create a new sprint from the green plus button:
6. Organize sprint planning meeting
Before each Version (Sprint) starts, the team should meet to discuss what tasks can be completed in the upcoming iteration, identify project priorities at the moment (as they might change), and also estimate any missing tasks from the prioritized backlog. Any planned leaves and holidays should also be considered.
7. Move issues from backlog to Version (Sprint)
Go to the Backlog tab. Decide which tasks are crucial at the moment and which of these can be completed in the upcoming Version (Sprint). When this is done, just drag the issues into the Version (Sprint) you created.
Please note that the new functionality allows having both Sprints and Versions in the Backlog tab:
8. Start the Version (Sprint)
Remember to add a due date for the Version:
And a start/end date for a Sprint:
The due/start/end dates really depend on a team schedule. For example, you can start a Version (Sprint) on Monday and finish on the following Monday. In the beginning, aim at the second week. But it will be much longer as well. It just depends on the particular needs and tasks for the project(s).
Organize daily stand-ups (ideally in the morning) - which is a great time to review each member’s work status and check for any problems in completing tasks. The meeting should be short and informative.
You can also check for current Version details. Just go to the Roadmap tab, and click on the Version name.
Note: Please note that the Roadmap feature is related only to the Redmine Versions.
In Redmine, you can find a feature called Agile charts, which contains a few very useful charts. They help you track the progress of the team as well as provide lots of information about velocity and productivity. More information about the charts could be checked here.
The Agile charts could be found in the upper right corner of the Agile board:
9. Complete the Version (Sprint)
In Redmine, when the Version is finished, you change its status to Closed. To do that, go to Roadmap, click on the Version you want to close, and then go to Edit.
When you close the Version, it will disappear from the Version planning table, but it will still be visible in the Roadmap right menu under Completed versions:
10. Organize a retrospective meeting
At the end of the Version (Sprint), it is a good idea to gather the team and hold a retrospective meeting. You can discuss what worked well and what didn't during the Version (Sprint). Other questions worth asking are: what can we do better next time? or what could we have done better now? A retrospective meeting is important for continuous improvement of the idea developed within the Agile methodology.
At this point, you should feel confident with how to create a backlog, work with Versions (Sprints), and organize daily stand-ups. This is how the whole Kanban/Scrum life cycle looks like in a nutshell.