As an agency that uses agile processes in software development on a daily basis, we are faced with various challenges: Since we do not build our own products, but realize a wide variety of web projects for customers, we regularly involve our partners in the feedback process and acceptance. In addition, our team always works in parallel on different projects that are in different development phases. Each project and each customer requires an individual adaptation of our agile process, but we always follow our basic principles.
Our agile process is a special procedure in which our client is closely involved and all work results are created in an incremental, iterative process.
This process is characterized by a responsible and trusting cooperation between both parties.
The individual orders are developed with the help of repeating 2-week cycles ("sprints"). The incremental process model used for this purpose describes the process of software development, in which the aim is to make the goal ("object of the contract") tangible by breaking it down into small work steps and to achieve continuous improvement.
Before each sprint, a meeting is held to work out and prioritize the product requirements to be developed ("Product Backlog"). All requirements are recorded using a project segment tool that is accessible to all persons involved in the project. As the project progresses, both parties work on the requirements together. The Product Owner maintains and prioritizes the Product Backlog regularly. The requirements are described in a brief scenario or process in as natural language as possible ("User Story").
Before the start of each sprint, a planning meeting is held in which the product owner and the development team, and at best also the project manager on the part of the client, take part. At this meeting, a detailed specification is made and it is agreed which requirements for the subject matter of the contract will be implemented in the upcoming sprint. A new sprint board is created for each sprint. Both parties regard this Sprint Backlog as the binding description of the requirements for the subject matter of the contract for the respective Sprint. The acceptance of the service will then take place at the end of the Sprint in a Sprint Demo. Requirements that are not fulfilled are considered as not accepted, are entered back into the product backlog and implemented in the next or a later sprint.
ROLES / WHO?
DEVELOPMENT TEAM
The members of the dev team have multidisciplinary competences and are self-managing, which means that all tasks that have to be done in the development process are carried out by its members on their own responsibility. Before each sprint, the team plans which tasks are to be completed and implements them in the work process of each sprint.
PRODUCT OWNER
The Product Owner's role is to ensure that the final digital product meets all the needs of different stakeholders (customer, user, etc.). To do this, they maintain a list called the Product Backlog, which is sorted by importance and contains all the tasks ("items") needed to achieve this goal. Prioritizing the items to be added to the product is one of his most important tasks. He determines these according to maximum value for the customer and in consultation with the various stakeholders.
For our customers, the product owner is also the account manager, a defined contact person during the project duration and during the ongoing further support.
SCRUM MASTER
The Scrum Master plays a crucial role in coaching the Dev Team and makes sure that the basic principles or Scrum rules are followed. His most important task is to provide the team with all resources necessary to achieve the sprint goal. He removes possible impediments, so that the dev team can concentrate on the task at hand and guarantees efficient and high quality output at all times.
LISTS / WHAT?
SPRINT
Scrum follows an iterative process in which each phase is called a sprint. A Sprint usually lasts at least 2 and maximum 4 weeks. The tasks that are completed within this period and added to the software product as items are precisely defined, estimated and prioritized before each sprint. At the end of each sprint the new features are tested and the dev team receives direct feedback on the product.
PRODUCT BACKLOG
The Product Backlog is a list containing all tasks that the product should receive. These so-called backlog items are often formulated in the form of user stories. Each item is estimated by the team and the Product Owner for its value to the end product and is prioritized higher or lower in the implementation process. A well maintained backlog should always contain enough items to fill a new sprint.
The product owner works closely with the project manager on the customer side to prioritize the backlog. To avoid delays, the customer project manager ideally has extensive decision-making powers.
SPRINT BACKLOG
The Sprint Backlog is the list of all tasks that have been scheduled from the Product Backlog Items for the current Sprint and that are completed by the team within the given time frame. The items are broken down into individual tasks in the Sprint Planning Meeting. The team members use their expertise to decide which tasks they can complete from the sprint backlog.
MEETINGS / HOW?
DAILY SCRUM
In a maximum of 3 minutes, each participant reports in the Daily Scrum which tasks he has worked on since the last meeting, which he would like to complete by the next meeting and whether there are any blockers that prevent him from reaching his goal or whether he needs help. The 3 core questions are:
- What have I done since the last meeting?
- What will I do until the next meeting?
- What tasks do I have and what help do I need?
SPRINT PLANNING
At the beginning of a Sprint, the team holds a Sprint Planning Meeting in which the Product Owner explains the tasks to be completed. Then the items from the product backlog are jointly entered into the sprint backlog to ensure that the sprint goals can be achieved.
REVIEW
At the end of the iterative sprint process, the sprint result is ideally presented in the presence of the customer, for example in the form of a demo. The presentation will show the progress made in the sprint and provide stakeholders with an insight into the status of the product. You can also provide direct feedback.
RETROSPECTIVE
At the end of a sprint phase, an internal improvement meeting is also held in which all members of the product development team reflect in a constructive and open manner on what went well from the sprint, what they learned and what can be improved in the future in terms of collaboration.
BACKLOG REFINEMENT
The task of Backlog Refinement is to prepare the items and gather all the necessary information so that they can be used as a basis for Sprint Planning and the development team knows what specific tasks need to be done. In this case, the exact form a process should take must be agreed with various stakeholders in advance. Often the effort of the items is also estimated by the participants (=Planning Poker)
Further terms in SCRUM
TASK BOARD
The status of each task (Task, User Story) is visualized via the Task Board. Task Boards can be maintained physically as a blackboard or, as with zauberware, digitally via project management software (e.g. Teamwork, Jira, Asana, Trello).
USER STORIES
A user story is the central element for describing requirements in an agile context. All user stories are recorded in the product backlog. "As a role, I want to achieve goals/desires to achieve benefits".
EPICS
Very roughly formulated user stories, whose implementation depends on a large number of individual items or tasks. Epics should be broken down into individual parts prior to sprint planning to reduce complexity, as they cannot all be planned into a time-limited sprint.
TEAM VELOCITY
The volume that the dev team can handle within a sprint. Ideally, the volume should be documented so that the team can better estimate the amount that can realistically be accomplished each time.
