First of all, it is a major challenge for a newly formed Team to find out how much of its development capacity is in a Sprint and how many Items it can schedule in a Sprint. At first, it is therefore advisable to run very short Sprints, possibly even weekly or biweekly Sprints, so that the Team can adjust in a timely manner. In the longer term, but not until adequate experience has been gained with the shorter cycles, the Team should move on to longer 3 or even 4 week Sprints, but then retain the Sprint running time.
In addition to the direct estimates, the project has of course some more planning tasks which must be met so that Sprints reach their goal. These other activities, such as the observance of scheduled vacation days and other availabilities and non-availabilities of team members, are organized in the Planning Meetings before each Sprint.
At different times during a project varied detailed levels of requirements are needed and each level has its own types of artifacts.
It ranges from a vision document (e.g. a classical project charter with a business case) to modeled business processes in the form of use cases, down to the specification of interfaces and GUI-prototypes as well as UML-application diagrams (e.g. class or sequence diagrams).
Diagram 22: Levels of the Requirements Specification
In large or very regulated project environments, such as the development of medical devices, such artifacts are mandatory to be produced, maintained and verified. Although the creation of the artifacts for a single requirement might be sequential, it does not mean that the process for creating all of the requirements is sequential. It is important to remember that only the requirements that make it to Stage 2 of the Product Backlog have to go through all of the steps.
Requirements do not simply come into existence. A requirement has to be worked on so that it can mature and finally deliver a ROI. Within an iterative process, the Product Owner works with his Stakeholders in order to maximize the benefit and, with the Team, find the best solution for a requirement.
The quality and understanding of a requirement increases through time. The whole process of refinement can also be seen as reaching a consensus of all of the Stakeholders.
Implement teamwork and communication: Product Owner, Team and Stakeholders work together on various levels to get the most value out of the project.
All of these formally looking steps can be done in accordance with the agile practice of close cooperation and communication.