TheTen: 10 Do’s & Don’ts of agile Software-development with complext business requirements

Software development has virtually invented agile projects. SCRUM, SCRUM masters and product owners are becoming increasingly important, and progress is planned, executed and tested in sprints. With today’s contribution in the series TheTen, our experts have summarized for you the ten dos and don’ts of agile software development, especially for complex business requirements. Whether you are an expert in software projects or not, you will hardly be able to avoid this agile approach in the future, because digitization is confronting us with increasingly complex technical and organizational requirements. At the latest with the use of artificial intelligence and increasing linking across the entire supply chain, we need agile and structured processes in software development. Find out how it works here.

1. Write smalluser stories.

User stories are the most important tool for managing projects in terms of content. They tell software developers what the customer needs and why. Small user stories can be described more precisely and implemented in a more targeted manner. The effort required can also be estimated better and more reliably. In addition, they can be easily scheduled in sprints.

Large user stories are difficult to schedule – simply because they do not fit into sprints. With a large story, you jeopardize the sprint goal because the user story must always be carried over to the next sprint. Large user stories also tend to be imprecise (because too short) or overcomplicated (because too long) descriptions, making them difficult to implement.

2. Write Epics.

Epics describe the requirements management context and thus provide the broad direction of the project. Each epic comprises several user stories which are planned and implemented in several sprints. Therefore, do not get bogged down in details. That’s what User Stories are for – Epics are about the vision, the big picture! If the common vision is understood by everyone, implementation will be easier.

3. Maintain the Product Backlog.

The product backlog consists of planned user stories and is managed by the product owner. Do not delegate the writing and management of user stories. Take your time, because the user stories in the product backlog describe the future of your product. Activelyshape your product!

4. Plan with lead time and feedback.

Plan user stories in the product backlog well in advance and get feedbackfrom all sides. In addition to the developers, later users should also be included. And: Don’t forget the stakeholders, because they also decide on the success of your product.

5. Start thinking about a suitable architectureearly on.

Architecture is a technical domain, but it has an extremely high impact on costs and medium- and long-term success. Therefore, the following, mainly non-technical, questions should be addressed as a minimum:

• How will the product be used?
• What is the vision of the product?
• What are the cross-cutting aspects?
• How many users are expected to use the product?
• How should the product grow and scale?
• For how many years should the product exist?
• How will the product be deployed?
• What interfaces should the product work with?
• What technologies are available?

When answering these questions, always consider the vision and market environment for the planned product. This is the only way to plan a suitable architecture.

6. Write tests.

By tests, are meant unit tests and end-to-end tests. (Agile) projects change quickly and can therefore easily change and break existing functionalities again. Therefore, automate tests and have them run at each so-called “build” (development stage). In addition, you should capture metrics such as test coverage (test coverage for quality assurance).

7. Write down technical debtas “user stories”.

So-called “technical debt” – potential consequences of poor technical implementation – slows down the medium- and long-term development of the product. You are only ever looking at the tip of the iceberg. If you are not aware of any Technical Debt in the product, there are probably a lot. Technical debt increases the development costs for further development until the project comes to a standstill. Therefore, work on technical debts in a timely manner, for example, by including them in user stories.

8. But: sometimes deliberately accumulate technical debt!

This may sound surprising, but in agile development it is always necessary to do “half-measures” to keep user stories small and to test concepts and generally get value and feedback quickly. Unlike point 7, you are aware of Technical Debt and can specifically weigh whether the higher development cost in the medium or long term until Technical Debt is resolved is worth it and helps the development process.

9. Don’ttry to controlevery detailduring the development process.

If you work with a good development team, they will organize themselves very independently and also make independent decisions now and then that will surprise you. That’s how it should be! Use the potential of your team and should the path taken by the team then deviate significantly from your ideas, speak openly about this.

10. Open up to the project team and actively live the principles of agile development yourself.

The more you are available to your team for questions and discussions, the sooner previously undiscovered problems and weaknesses can be identified and resolved. Every project comes to crossroads and forks in the road. The more solid the vision of the common goal is in your team, the easier it is to take the right direction together at these forks.

Now it’s up to you. Start agile with your team. Stick to our Dos and avoid the Dont’s. If you have any questions, feel free to contact our experts.

Our Experts