Agile Project Management with GitLab vs JIRA
We decided to stock our codes, done product developments on GitLab lately. Formerly, I have used JIRA, Microsoft Project, Microsoft Excel in order to plan, track and monitor projects. While we stop using stash, I tested GitLab if it satisfies our backlog/project management needs.
There were two reasons. First, DevTeam and I could lead projects from a single platform. Second, GitLab enables us to track 4 Core Metrics: Cycle Time; Lead Time, MTTR, CFR. I listed all of the requirements that I use while leading projects on JIRA.
Product Backlog
- Create userstories
- Edit userstories
- Move userstories within projects
- Add image/folder
- Add detail to userstories
- Labeling
- Create epic
- Prioritize
- Storypoints/Weight
- History
- Comment
- Listing
Scrum Board
- Status
- Drag/Drop Cards
- Assignee (Both test/dev)
- Sprint Creation
Monitoring Performance
I demonstrated a demo to see if GitLab satisfies what JIRA offers me as a software.
Review:
How to Apply
GitLab’s wording is a bit different than our language. Issue corresponds to “user story” in our context. Milestone is same as “sprint”. Weight is “story point”.
While using GitLab, you can a create user story and simply add details, assign ownerships, story point, epic, sprint, labels to it.
Product Backlog
Creating/Handling Product Backlog
Issues should belong to a Project. First, you create a Project and name it “Product backlog”. Then create an issue to this project.
User story details can be added to the description of the issue. All that “given,when,then” and “scenarios” jazz. And also, you can attach files on it. Furthermore, you can assign multiple people to a user story which helps us see who is responsible for development and test.
You can also link dependent user stories. Since we aim to connect user story to api’s, a user move user story(issue) to another Project ( “example-api”) by simply clicking “move” button.
Adding User Stories to a Sprint
You can create a sprint by using a milestone. Just name the milestone as “Sprint number”, select a Start and End Date. That’s it.
Now you are able to add user stories to a sprint. If you want to state any detail information about the sprint, you can use milestone’s description. You can set a milestone for a specific project or a group. While creating sprints, be careful about it ✌️
Adding Labels
You can add labels to your stories. Labels are fully customizable, and we will further use it while generating our board.
You can select color of the label which could help us to visualize importance. For example you can add a “bug” label and select color red.
ScrumBoard
My personal favorite feature on GitLab is fully customizable issue boards so far. You can name a board as “development” then you add list and select labels to be shown on board such as “Dev-in-Progress, Dev-Done, Test-in-Progress, UAT” etc.
You can simply drag and drop user stories(issues) within status(labels) which enable us to track the flow of work. Other labels are still seen on the user story cards. You can distinguish which card is “pair,bug,prod-bug,sprint-bug” etc.
Moreover, you can create multiple boards, add filters and use it for different areas such as technical analysis, ux/uı analysis and so on. If you want to use a board for your technical analysis. Just create labels like “TA-Needed”- “TA-Done”. Create a “tech-analysis board”. Select the board. Filter it for the sprint(milestone). Then ta-da you have a board for technical analysis for the future sprint.
Monitoring Performance
Epic Roadmap gives you the opportunity to visualize epic performance. It visualizes deadline, weight, percentage of completed work (if you set weight). You can set your epics deadline manually or feed it from sprints. You can also visualize epic’s timeline and sprints(milestones).
If you open a milestone, you can see burndown chart. Besides that, GitLab enables bunch of new analytics. But that should be a new article 😊
Conclusion
I was thinking that on gitlab issues are either open or closed. When I used it, I see that you can generate your own status. Fully customizable multiple boards will be useful in a future. It presents epics in timeline format that JIRA doesn’t offer, is game-changing from the roadmap view.
By the way, there are some cons. First, I sometimes stuck on navigation. I lost my way while creating labels, boards, milestones. For example, I created a milestone to a project, not a group. Then I wanted to start a sprint, but it applied only on one project. Second, there is no control over status, such as you can add a user story without story point on a sprint.
To sum up, my user-experience as a product manager is very similar to JIRA. Gitlab satisfies all of my needs and requirements. Furthermore, it is much more flexible. Teams can adopt software easily and change it according to their needs.
