While the core principle remains the same, Agile methods divide into two main types: Scrum and Kanban. Each type has its own advantages and disadvantages, which are utilized by software development and IT operations teams based on their needs.
What is more, the most commonly used project management tool is Jira, and the documentation tool from the same company is Confluence. Having proficiency in using these two tools is vital for any stakeholder to work harmoniously on software development projects.
Scrum is the most common approach, mainly used by product teams that implement new functionality. In this approach, new functionality is written as work items called Stories—essentially tasks that describe the business and technical requirements for the software developers on the project. Each Story is measured with Story Points defined by that Scrum team, which estimate the subjective man/hour effort based on their own specialized pace. The value of Story Points is unique to each product team, as each team has its own way of working and performance metrics. For instance, Product Team A might assign 3 Story Points to a new implementation, while Product Team B might give 8 Story Points for the same Story. This depends on the maturity, resources, and experience of each product team to measure this performance metric.
Once each Story, Task, and Bug issue is measured in terms of Story Points, the team holds a prioritization meeting to select which ones to carry into the next iteration. Each iteration in the Agile world is called a Sprint, and each Sprint has a limited number of Story Points to work on. This represents the agreed-upon fixed number of points that the team forecasts as a doable amount of work effort for that Sprint. Generally, Sprints take 2 weeks, but this can be adjusted from 1 week to 3 weeks based on the team’s needs.
Kanban is mostly used by IT Operations teams or product teams where iterations cannot be made in fixed sprints. In such teams, the pace of incoming tasks is spontaneous and mostly ad hoc. This reflects the nature of operational support, where you cannot always predict what kinds of requests might arise from stakeholders. The main goal is to receive the backlog from all requesters, prioritize by severity on the go, and keep this process as transparent as possible—without overlooking minor issues or creating bottlenecks.
The following infographic was generated by Google Gemini to visualize the specifics of this methodology:
