Project initiation “The Initial Sprint”
We are pleased that you have contacted us and are considering implementing your individual software project. In order to offer you assistance in making a decision and at the same time to be able to create the most precise project planning possible, we carry out an “initial sprint”. Central points of the “initial sprint” are:
- Requirements analysis (viewing, formulation and expansion of user stories)
- Goal definition
- Creation of the initial product backlog
- Outline of the overall system (technologies, APIs, idea of the data model)
- Application workflow
- Initial sprint and release planning
- Risk assessment
- Summary and price range for the entire project
For the “initial sprint” we usually plan 2 weeks of close cooperation with you (approx. 80-100 hours). We only charge the “initial sprint” if the project does not materialize. The background is that in the course of this sprint many project details are worked out, which already represent an enormous benefit for you and the project in terms of content. With the findings of this sprint, nothing stands in the way of a direct project start for us from a technical point of view.
Role of the client
As the client, you have the project idea and – to put it casually – know where the journey should go. In order to be able to convey this to the development team from a technical point of view, provide at least one person in charge who takes on the role of product owner. Two people are welcome to take on this role, which can be helpful in substitution situations but also when distributing responsibilities and the time commitment. In this case, it is important that both people have equal rights in exercising the role of product owner. It is also crucial that this person is largely, ideally completely, freed from day-to-day operations. Only in this way is it possible, from our experience, to dedicate oneself completely to the project and, above all, to be able to contribute technical expertise.
A successful project is largely dependent on the technical competence and availability of the product owner, as this is required in almost every aspect of the agile approach.
Another important task that you have to fulfill in the role of product owner is the definition of requirements on a functional level, called user stories. Such user stories define acceptance criteria that are crucial for acceptance. From the user stories, the development team will later define specific technical tasks that are necessary to realize a user story.
As the product owner, you are in close contact with the development team in the course of this process and, over time, you will get a feeling of being able to better assess your requirements and transfer them to the release planning. Furthermore, the creation of tasks from user stories is of particular importance, as you receive feedback on the scope and effort and can intervene directly to expand or limit requirements, always with regard to time and costs.
We are happy to support you, especially at the beginning, with the formulation of user stories and acceptance criteria.
With an agile approach, the seemingly lacking ability to plan, i.e. to be able to make time and cost estimates, is often a deterrent at the beginning – also due to a lack of or little experience. However, with increasing experience from agile projects, you will find that the risks of time and cost overruns are significantly lower than with classic projects. Release planning is important for basic planning, which is not set in stone and can dynamically adapt to changed conditions and requirements (product backlog).
As a product owner, you plan fundamentally which user stories are to be implemented or completed in which iteration cycles. Thus, a plannable number of iteration cycles can be targeted, with which the costs can also be calculated. Such release planning becomes more and more precise with increasing project progress and experience in estimating expenses, ideally in close cooperation with the team.
Role of the development team
Depending on the project, we provide a development team that works closely with you and is in constant communication. In addition, we provide a Scrum Master to monitor the agile approach, who supports the team in its daily work with organizational and technical support and removes obstacles. The Scrum Master thus has the backs of everyone involved, so that an optimal focus on the actual tasks is given.
Iteration cycles (sprints)
We recommend iteration cycles, also called sprints, with a duration of two to a maximum of 4 weeks. After each sprint, the tasks contained therein must be completed and a piece of usable software must be created. Each sprint is coordinated with you in detail so that only topics are processed that are relevant and necessary for you. As a product owner, you can therefore intervene in the direction of development at any time, thereby avoiding “extra rounds” or unnecessary effort.
At the beginning of a sprint, you and the development team do the sprint planning together, i.e. which specific tasks are necessary to achieve specific requirements (user stories). At the end of a sprint, there is a review appointment, at which the acceptance is also carried out.
With each sprint review and the associated acceptance by you, the sprint is billed. The hours incurred are billed at the agreed project hourly rate. In order to ensure full transparency, you will be given a list of every hour incurred. Each hour can be assigned to the specific tasks and thus the underlying user stories.