Repository navigation
Reflection
In retrospect, several positive aspects of the project can be highlighted. A key success was the timely completion of all planned sprints. The developed application is functional and usable, which confirms that the objectives were met. Overall, the estimated time for each sprint was quite accurate, although approximately 20 additional hours per sprint were necessary in the first two sprints. The last sprint took a lot longer than anticipated, but we had already planned to invest more time into it since we had some spare time over christmas break. Since we already figured out a good velocity for the first sprint, we could plan the other ones a lot faster.
Another positive factor was the consistent and even distribution of tasks throughout the weeks, as reflected in a solid burndown chart. Weekly meetings every Tuesday provided opportunities to discuss the current status and collaborate efficiently during co-working sessions.
Team communication was also smooth and efficient. A Discord server with thematically organized channels, along with a group chat on WhatsApp, ensured clear communication and accessibility. When needed, Discord calls combined with co-working sessions were used to resolve open questions.
Working with Git proved to be highly effective, as each pull request was reviewed by at least two team members. This approach fostered active discussions and ensured high code quality. Since the pull request needed to pass several other requirements as well before being able to be merged, it gave us a lot more security.Read our branching rules here.
The working atmosphere was described as very pleasant, characterized by mutual sympathy, helpful collaboration, a conflict-free environment and a shared sense of humour, complemented by a strong team spirit.
Despite the many positive aspects, some challenges arose, offering opportunities for improvement in future projects. One notable weakness was the insufficient description of tickets, which occasionally led to unclear task definitions. We addressed this issue by actively seeking input and clarification from other group members, ensuring the tickets were eventually understood. However, it would have been more efficient to write clearer ticket descriptions from the start to avoid unnecessary time spent discussing and interpreting them. Additionally, time estimates for tasks were sometimes inaccurate, particularly in the division between frontend (underestimated) and backend (overestimated). However, this improved with each sprint and ultimately balanced out.
Another challenge was the insufficient time allocated for learning and implementing new technologies. For instance, the development of the app turned out to be far more time-consuming than we initially anticipated, as none of us had significant experience in app development, particularly with the technologies we chose to use. This lack of familiarity led to some suboptimal outcomes, as certain tasks could have been handled more efficiently with better preparation. At one point, we even doubted whether the implementation was possible at all. However, through extensive research and persistent trial and error, we eventually found a solution. While we are proud of overcoming this hurdle, earlier preparation and a smoother process would have been preferable and led to better results in this area. Since we implemented the app in the third sprint, it resulted in much more time than we had initially planned. Similarly, building our UI kit turned out to be much more effort-intensive than anticipated, requiring significant additional time. In the final sprint, we encountered far more bugs and errors than we had anticipated, which required significant additional time and effort to resolve. We should have considered this happening when planning the sprint, and will do so in the future.
At the beginning of the project, too many tasks were planned, resulting in a large backlog. While the remaining tasks were mostly of low priority, a more realistic initial plan could have better distributed the workload. Even though the priority of the remaining tasks was not high, it was disappointing to be unable to implement everything we had planned.
Sprint planning was another area for improvement, as it was often done on the last evening of the sprint. This led to concentration challenges and a “last-minute” feeling. Conducting the planning earlier in the week would have been more effective.
Working on the project was largely positive, with well-structured collaboration and a positive working atmosphere as key highlights. We can 100% recommend using a discord server for communication and organization, and have already used this on other projects as well. Figuring out a good velocity for sprints was also a key factor for effective sprint planning. We were happy to see that planning sprints and tickets became more accurate over time. Only in the last sprint did we underestimate the bugs that occurred and had to exceed the time planned for our tickets. The identified weaknesses provide valuable insights for improving future projects and achieving even greater efficiency. We have learned to not underestimate areas we do not have prior experience in and will research new technologies more thoroughly before deciding to work with them. Planning sprints earlier in the week would also result in the planning not being so rushed, which would also improve the ticket descriptions.