Agile Projectmanagement Glossary
Originally, the Kanban-method comes from production control. In the course of agile product management however, Kanban was also discovered as a method. At its core is a visualisation board with three columns: “Backlog”, “In Progress”, and “Done”. Tasks are fixed as such on sticky notes, so that these can be visualised accordingly. All to-dos are noted in Backlog. As soon as a task is undertaken, it moves into the second column, In Progress. Once the respective task is completed, it is put in the third column, Done. Every team member is allowed to take and begin new tasks.
Scrum is a method for agile product management. Its origin lies in software development, however it is now finds cross-industry application. Features of scrum are among other things simple rules, few meetings, as well as self-organisation and autonomous action in interdisciplinary project teams. The aim is efficient and cheap implementation of product visions. Scrum knows four functionaries that drive the development process:
- Product Owner
- Scrum Master
- Development Team
The product owner has the product vision that is to be developed. The product owner makes technical requirements regarding the product and prioritises these.
The development team develops the product. It is in charge of the distribution of user stories into feasible tasks, as well as estimating the respective initial cost and implementation.
The scrum master is in charge of compliance with the scrum rules and is responsible for the sprint being successful in the end. They work closely with the development team, while still remaining outside the team. Besides moderation and correction of disruptive factors, the scrum master controls communication within the team and with the product owner.
The Stakeholder may be, for example, a customer with an idea or vision that is to be realised. They are the client for the product.
This backlog contains user stories that the product owner has created in cooperation with the stakeholder.
The backlog contains the tasks.
These describe the requirements from the perspectives of a user, while using a precise statement. The user story describes the product characteristics.
A sprint is a predetermined time period, usually taking two weeks, in which the tasks (sprint-backlog) decided upon in the sprint-planning are processed. At the end of the sprint, these are are removed in the sprint-review. In the sprint-retrospective, those things that went well (positive) and those that did not go well (delta) are noted down in a positive/delta list, in order to handle the next sprint better. The proposed time for the tasks determined in the sprint-planning should not exceed the sprint timeframe.
The sprint-backlog contains all the tasks for the current sprint. It is determined by the development team and the product owner.
The product owner proposes their prioritised product backlog to the development team. The characteristics and acceptance criteria are discussed together with the team. Afterwards, the team determines which user stories from the product backlog are achievable in the next sprint and a sprint goal is formulated together.
In the second part of the sprint planning, the user stories chosen in sprint planning I are translated into separate tasks.
In the daily scrum, which goes for a maximum of 15 minutes and is ideally done standing, the following 3 questions are always cleared up with the development team and product owner:
- What has been achieved since the last daily scrum?
- What will be achieved until the next daily scrum?
- Were there any problems? And, if so, which.
The sprint review is conducted at the end of every sprint. There, the achievement of a sprint’s aims are examined. The primary aim is to validate the implemented functions and to ensure that these have been implemented according to the stakeholder’s wishes. The feedback resulting from all participants is particularly important in order to let the gained insights flow into the next sprint backlog.
In the sprint retrospective, the team notes down the last sprint in a positive/delta list. With this list, the working methods so far can be evaluated, so that in future these can be implemented even more effectively and efficiently.