What is Agile Project Management in Leantime?
While agile is not directly promoted in Leantime, we recognize the value in the concepts. It is one of the methodologies that our system adapts from and we do incorporate these features in order to allow users to continue their agile practices. At times, we've added some flexibility into these concepts in order to be friendly for both engineering teams and non-engineering workflows.
Agile project management is a software development methodology that started as a counter to waterfall development practices.
In waterfall development, you would typically wait until larger features were developed or until the software was done completely. If you were a startup software company, that might mean you wait 2 full years until you have a product in the market. There are too many changes in the economy, environment, and software world now to wait 2 years for user or customer feedback.
In software, the definition of done is really never defined. Technology changes, code needs to be updated, customer needs and goals change and there are always updates to UX/UI best practices as the software ages. Agile exists to cope with both previous experiences of development and also to cope with the absence of "done." The goal then is to create value (features, or code releases) in set & timed phases of development; and in doing so, creating a more flexible and adaptable approach to development.
Instead of delivering the project or work only when it's done, agile requires you to break down the work into smaller groups of tasks. As you decide what those groups of tasks look like, you can then move them into a Sprint (a decided time frame: often 2 weeks) in which you want to complete them.
When you break the work into smaller tasks, and then again into a dedicated time frame for that work, if something in the project changes during the two weeks: you can still make changes for the upcoming groups of tasks while still working towards the same goal.
One other thing that you may not see traditional agile frameworks discuss: In working in smaller groups of tasks, you can decrease the information and work overload that can come from larger & overwhelming tasks. As a result, this tackling tasks like this will also support work motivation and reinforce the path to the goal by showing incremental progress.
Kanban is part of agile project management. It is the visualization of the activities / tasks needed to complete the development of the product/project. In Leantime, they are visualized in columns as: New, Blocked, In Progress, In Review, Done. These columns are editable within Leantime and so you can change them to represent what you want. In traditional form, though, the tasks will be defined, assigned and will travel throughout the columns until they reach the Done category. In Leantime, you’ll also have an archived category that is not visualized on the board itself.
In Leantime, the Kanban view has been combined with some of the second component of agile: Scrum.
Scrum is a process framework within agile that helps to guide the iterative process. The goal of which is to increase the the quality of deliverables, improve change management (changing requirements, provide more realistic time estimates, and offer more control over project/product dates and timelines. While Scrum has quite a few working components, for our purposes, we’ll discuss the ones specific to Leantime.
A Scrum Sprint is a month long, or less, actionable push that is intended to finish with a quality deliverable, or releasable product increment is created. As part of the building process, one would create a actionable tasks, assign and incorporate into this release. There are then tasks that remain as part of the product but are held for later Sprints. In Leantime, on the Kanban (To Do) view, you are able to create timed Sprints, associating specific tasks within it. On the Table view, you can see both the tasks in this Sprint.
For those looking for a backlog view, the Table View is intended to accomplish this by giving a complete task overview.
Maintaining rapid iterative pace means that you're taking the time improve the process each time as well. In agile, that means implementing retrospectives.
Improvements must be made in sequence with development otherwise any missteps, inefficiencies or problems may be missed or simply repeated.
At the end of every Sprint, a brief Retrospective period should be done.
In Leantime, we include retrospective boards that allow team members to include feedback of what went well, what needs improvement, and what should be continued for the next sprint.
In Leantime, this is visualized in a similar Kanban format.
For Scrum, and product development in general, an estimation of effort is useful in determining how much work and time is required to get to “Done”. This is important because it allows us to better plan for resources such as budgets or available team members.
As a general rule, people can struggle with task estimations -- knowing how long a project or task will take is challenging.
To better standardize this experience, Scrum uses effort to describe the complexity of the project. When we better understand the complexity, we get better at estimating. Scrum calls this “Story Points.”
In Leantime, these are “T-shirt Sizes.” T-shirt size is defined by the team as estimations within a task. The team averages that a certain task is a “small” task and this second task is an “XL” task and so forth.
As your team gets better at estimation, you can start to recognize that an XL task takes an average of 10 days vs a small task being only 2 or 3 days.
Velocity is another important concept within Scrum. It is the amount of work your team can accomplish in a single Sprint.
To calculate Velocity, the amount of effort completed at the end of the Sprint is used. This could look like, "3 XL t-shirts, 2 medium, 1 small." This can then be used to measure and plan for outcome improvements and task/Sprint estimations.
In Leantime, velocity can be visualized under the Reporting Menu.
What is agile project management?
Agile project management is a software development methodology that started as a counter to waterfall development practices.
In waterfall development, you would typically wait until larger features were developed or until the software was done completely. If you were a startup software company, that might mean you wait 2 full years until you have a product in the market. There are too many changes in the economy, environment, and software world now to wait 2 years for user or customer feedback.
In software, the definition of done is really never defined. Technology changes, code needs to be updated, customer needs and goals change and there are always updates to UX/UI best practices as the software ages. Agile exists to cope with both previous experiences of development and also to cope with the absence of "done." The goal then is to create value (features, or code releases) in set & timed phases of development; and in doing so, creating a more flexible and adaptable approach to development.
How does agile work?
Instead of delivering the project or work only when it's done, agile requires you to break down the work into smaller groups of tasks. As you decide what those groups of tasks look like, you can then move them into a Sprint (a decided time frame: often 2 weeks) in which you want to complete them.
When you break the work into smaller tasks, and then again into a dedicated time frame for that work, if something in the project changes during the two weeks: you can still make changes for the upcoming groups of tasks while still working towards the same goal.
One other thing that you may not see traditional agile frameworks discuss: In working in smaller groups of tasks, you can decrease the information and work overload that can come from larger & overwhelming tasks. As a result, this tackling tasks like this will also support work motivation and reinforce the path to the goal by showing incremental progress.
Kanban
Kanban is part of agile project management. It is the visualization of the activities / tasks needed to complete the development of the product/project. In Leantime, they are visualized in columns as: New, Blocked, In Progress, In Review, Done. These columns are editable within Leantime and so you can change them to represent what you want. In traditional form, though, the tasks will be defined, assigned and will travel throughout the columns until they reach the Done category. In Leantime, you’ll also have an archived category that is not visualized on the board itself.
In Leantime, the Kanban view has been combined with some of the second component of agile: Scrum.
Scrum
Scrum is a process framework within agile that helps to guide the iterative process. The goal of which is to increase the the quality of deliverables, improve change management (changing requirements, provide more realistic time estimates, and offer more control over project/product dates and timelines. While Scrum has quite a few working components, for our purposes, we’ll discuss the ones specific to Leantime.
The Iterative Process: Sprints
A Scrum Sprint is a month long, or less, actionable push that is intended to finish with a quality deliverable, or releasable product increment is created. As part of the building process, one would create a actionable tasks, assign and incorporate into this release. There are then tasks that remain as part of the product but are held for later Sprints. In Leantime, on the Kanban (To Do) view, you are able to create timed Sprints, associating specific tasks within it. On the Table view, you can see both the tasks in this Sprint.
For those looking for a backlog view, the Table View is intended to accomplish this by giving a complete task overview.
Retrospectives
Maintaining rapid iterative pace means that you're taking the time improve the process each time as well. In agile, that means implementing retrospectives.
Improvements must be made in sequence with development otherwise any missteps, inefficiencies or problems may be missed or simply repeated.
At the end of every Sprint, a brief Retrospective period should be done.
In Leantime, we include retrospective boards that allow team members to include feedback of what went well, what needs improvement, and what should be continued for the next sprint.
In Leantime, this is visualized in a similar Kanban format.
Effort & Velocity
Effort
For Scrum, and product development in general, an estimation of effort is useful in determining how much work and time is required to get to “Done”. This is important because it allows us to better plan for resources such as budgets or available team members.
As a general rule, people can struggle with task estimations -- knowing how long a project or task will take is challenging.
To better standardize this experience, Scrum uses effort to describe the complexity of the project. When we better understand the complexity, we get better at estimating. Scrum calls this “Story Points.”
In Leantime, these are “T-shirt Sizes.” T-shirt size is defined by the team as estimations within a task. The team averages that a certain task is a “small” task and this second task is an “XL” task and so forth.
As your team gets better at estimation, you can start to recognize that an XL task takes an average of 10 days vs a small task being only 2 or 3 days.
Velocity
Velocity is another important concept within Scrum. It is the amount of work your team can accomplish in a single Sprint.
To calculate Velocity, the amount of effort completed at the end of the Sprint is used. This could look like, "3 XL t-shirts, 2 medium, 1 small." This can then be used to measure and plan for outcome improvements and task/Sprint estimations.
In Leantime, velocity can be visualized under the Reporting Menu.
Updated on: 04/12/2024
Thank you!