© 2023 v_labs innovation GmbH.Read our Imprint or Privacy Policy here.
If you're using the Scrum framework for or within your venture, you know there can be some challenges along the way. In this blog post, we'll introduce you to three stumbling blocks and show you how to overcome them. With the right approach, you can keep your Scrum project on track and avoid these common pitfalls.
If you're using the Scrum framework for or within your venture, you know there can be some challenges along the way. In this blog post, we'll introduce you to three stumbling blocks and show you how to overcome them. With the right approach, you can keep your Scrum project on track and avoid these common pitfalls.
But let's take a step back…
The Scrum method is a framework for agile product development and agile project management. At V_labs, we use Scrum mainly for the software development parts of our company buiding projects. It provides a clear definition of roles, meetings and processes. Small teams work as self-organized units. Only the direction is given to them from the outside, the tactics for achieving common goals are determined within the team. If you are completely new to Scrum, you should first dive into the basics of Scrum (We recommend scrum.org, where the framework is regularly developed further. You can also get more information in our Company Building book, chapter 8).
In addition to the obvious challenges in Scrum projects, such as lack of communication, clear and measurable goals, poorly defined roles and responsibilities, and non-compliance with the Scrum framework, we would like to address in particular the stumbling blocks that can easily be misinterpreted or misunderstood.
Each sprint includes a series of Scrum meetings, which have a defined goal and a regulated timebox, as specified in the framework. This ensures a very efficient and good meeting culture. Here is a brief overview of the duration of meetings as specified in the Scrum Framework:
With a sprint duration of 2 weeks, this means that a total of 14 hours are blocked for the Scrum meetings only. As a result, developers not only lose pure development time, but have to interrupt their work again and again. (It is also every Scrum Master's nightmare to find an appointment for 6-10 people in today's meeting jungle, because even when starting a new Scrum project we rarely start with an empty calendar).
So in practice, each team has to figure out for themselves how much time they really need for each Scrum event. Don't get us wrong: the goal is not to reduce meeting hours to a minimum overall, but to optimize them. One way to find out is to take the first sprint as a test where the required time is stopped. Based on the results, serial appointments can then be sent out. In addition, meetings can be bundled so that focus time is not interrupted too often. Review, Retro and Sprint Planning fit together very well, but don’t schedule them in the middle of the day, plan them in the morning or in the afternoon.
User stories describe the requirements from the user's point of view. If you look for information about user stories, you will mostly find information about the structure of a user story in the following form:
"As a [user], I want [function] so that [benefit/value]."
But to really work with User Stories you need more than that! How is a developer supposed to know what he/she has to fulfill? And how is a tester supposed to know what to accept? Similarly, the user story itself leaves out any information about edge cases and error and success flows.
Now, one might argue that if a user story contains all this information, a developer needs more time to work on a user story, and there we have the dilemma described above: detailed user stories come at the expense of productivity. So how can we overcome the stumbling block?
The pragmatic answer is: as much as necessary, as little as possible!
A typical user story card at V_labs contains, in addition to the above formulated user story, the business logic, acceptance criteria and optionally edge cases, error and success factors, as well as the content. It is sufficient to formulate stories in bullet points. For static screens such as a contact page, all optional information can be omitted. Thus it is directly clear that no edge case or error and success factors have to be considered. In contrast, in the case of e.g. a login, edge cases, error and success factors must be taken into account, which is why it makes sense to describe the user story in detail. Another tip to save time: Formulate your user stories directly in designated tools, such as Jira or YouTrack.
Let's talk about lack of design lead time, legal issues, and undeveloped technical concepts that can stall your project. If you look at the Scrum roles, you will find the Product Owner, the Scrum Master and the developers. The latter are described as people who work together to create the product, so that includes the designers and tech leads. And here is something you should keep in mind:
Even if the Scrum team includes the designers and tech leads, their work must be scheduled with lead time. It is therefore not enough to simply create tasks for the concept and design and subordinate them to a user story. Otherwise, you risk developers not being able to do their job because there are too many unresolved issues. This not only has a negative impact on the product, but also on the collaboration!
Instead, you can use a product roadmap to plan roughly when a feature is to be implemented. Accordingly, the technical concept must be created, if necessary legally clarified and then designed. Each of the 3 components can take some time, you certainly know that from other projects. However, it is important that features are not planned in a sprint when the technical concept has gaps, legal has not been approved or the design is not final yet. The definition of ready should then simply not be given, even if it is only a small thing that can be added afterwards.
By understanding these stumbling blocks and taking steps to overcome them, teams can improve their chances of success when working on Scrum projects. Remember, Scrum is a flexible methodology and it’s important to be open to adapt and adjust as needed. Regular retrospectives are an essential part of the scrum framework and should be used to identify and address any issues that arise.
In addition, it is worth mentioning that when Scrum is newly introduced in an organization, it is recommended to follow the rules closely. As a heuristic framework, it assumes that with increasing experience, the Scrum process will also be adapted to the team. It is therefore in the nature of Scrum that the initial dogmatism is increasingly replaced by pragmatism and the mentioned stumbling blocks can be overcome.
