Before the actual development in Scrum there is also of course the project planning and the design of the rough architecture.
In the project planning, specifications for the project are defined: for example, which employees participate, what development tools are used and what conventions should be adhered to. In this context, the first version of the Product Backlog (collection of the requirements) will also be created. This can take place before the actual Scrum process or be collectively worked out by the Scrum Team within the framework of a first Sprint.
Diagram 10 shows the Scrum process, the defined artifacts and also the scheduled meetings:
Diagram 10: The Scrum Process
The Scrum process is practiced in various meetings and as a result provides some artifacts which are described below.
The Product Owner creates a list of requirements based on the description of benefits – the Product Backlog. The order of the entries at the same time sets their priority. All of the Stakeholders contribute to its content. This not only happens at the beginning of a development and not just at certain times, but as an on-going process. Once change requests or new requirements emerge, they are inserted into the Product Backlog. This fundamental openness to accept constant changes and view them not as obstacles but as opportunities, leads to high flexibility in the development. The prioritization is often based on the goodwill value of the business or on a risk involved with the requirement. This allows for quick reaction to changing conditions without jeopardizing the project.
A Product Backlog can, for example, have the following form:
Table 1: Example Product Backlog
The Sprint Planning Meeting takes place at the beginning of a Sprint and all project members participate. This is where the Team and the Product Owner decide on the contents of the next Sprint.
The Product Owner defines the highest priority entries (“Items”) of the Product Backlog and explains their functional use. The Team estimates the effort of the “Items”.
The Team selects the “Items” for a Sprint from the Product Backlog in accordance with the prioritization and then puts them into the Sprint Backlog.
Once the Team and Product Owner agree with the implementation of the Sprint Backlog in the next Sprint, the Sprint Goal is defined.
After that, the Team adds the Sprint Backlog “Items” to an implementation plan. These are mostly specific development activities.
The Sprint then starts. For the sake of stability, the requirements of the Sprint Backlog should not change during a Sprint.
As soon as the first Sprint has started, each Team Member can add the so-called impediments (Blockers) to a list. Each Team Member announces their Blocker for the implementation of a task as soon as it arises and places it in the list of Blockers. It is the task of the Scrum Master to eliminate these Blockers. A Blocker may be a framework condition, but could also be the wait for an unfinished task. The Blocker is conveyed to the other Team Members in the Daily Scrum Meeting and recorded in the Impediment List.
Example of an Impediment List:
Table 2: Example of an Impediment List
Table 2 represents an example of an Impediment List. Further columns can of course be added. Where applicable, a status per line could be worthwhile if the list should not only include outstanding Blockers.
Once a Sprint has started, the Team meets at the Daily Scrum Meeting. The Daily Scrum Meeting is an informal meeting lasting maximum 15 minutes. In this meeting, each team member has to answer the following three questions:
This meeting is not an extensive discussion, but the teams short daily planning meeting to coordinate the necessary tasks to reach the sprint goal. It is the Scrum Master’s task to ensure this happens.
The Scrum Master’s main task is to resolve emerging Blockers. His task is not to guide the Team. The Team is self-organizing.
The following guidelines apply to the “Daily Scrum”:
At the end of each Sprint there is a “Review Meeting”, in which the Team presents the results to the Product Owner and other Stakeholders. Everyone can participate in this meeting and give feedback on the results and their development. A review of the Sprint (the retrospective) also takes place at the end of a Sprint. The whole Scrum Team is invited to this. What should be improved in the future is discussed at this meeting.
A principal value of Scrum is the ability to integrate new requirements into the system after each iteration and Sprint. With each step the customer receives an executable system which, in the course of time, becomes increasingly like the end product. Unlike other iterative development models, Scrum not only focuses on executable systems, but also on actually usable systems. So, the development of a complete system should not be separated into individual modules that cannot realistically be used without the complete system. This avoids the customer not receiving a product which can actually be used by the users until the very end of the development process and then having change requests arise. The principle here is that the customer should not get what he has specified but what he actually needs. The prioritization of the requirements according to the goodwill value of the business also ensures that the customer can use his most important functions at an early stage.
How can a deadline for completion of the product be determined at the outset when using an agile approach like this? How can you plan your time and budget for the overall development? The answer is: in general, not at all. Even the approach which allows on-going changes prevents such efficient planning. As a rule, after a few Sprints, an executable “End version” can be handed over to the customer. He will now determine whether or not there are still more change requests and if further Sprints should take place.
Nevertheless, to be able to plan the time and budget for the overall development, “Timeboxing” is frequently used: It is made available to a specific Time/Budget-Contingent, however, without being able to adjust the project results contractually. An estimate of what can be implemented in this time period can still be made – but never in such detail as it is done in classic models. It is however debatable whether a detailed statement regarding the possible development time and cost generally reflects reality for larger developments. According to a survey (“Chaos Report” by the Standish Group from 2004), about 2/3 of all projects worldwide exceed the calculated project costs or the duration, or fail completely.