January 12, 2024
Get in touch
The world of software development has changed significantly in recent years. For a long time, software development projects were carried out according to a fixed plan, where each phase was meticulously planned and documented (the 'Waterfall' approach). However, for some time now, a different approach has established itself: agile software development.
Have you always wanted to know what a day in the life of an agile Scrum team looks like? We'll take you through a typical day in the various Scrum roles at AOE GmbH. Today, Theresa, a backend developer with a focus on security, will take you through her day:
Tomorrow we have our regular Backlog Refinement meeting again. Although we will discuss questions and uncertainties during the meeting, it often pays off to talk about these beforehand with the Product Owner. So, I'm already picking out the highest-priority User Stories in our backlog and asking myself if I know everything I need for their implementation. I pay special attention to requirements that affect old or fundamental sections of the product, where I might need to refresh my knowledge or gather information from colleagues in advance.
Occasionally, I also create User Stories that have (security-)technical relevance for the software, which I discuss with the Product Owner before the Backlog Refinement. In doing so, it's not only important to explain well what the benefit for the customers is, but also to make clear what the implications are (or could be) if the User Story is not implemented.
When it's time for the Backlog Refinement, I'm already prepared: I know which User Stories we will be discussing, and I can focus entirely on listening to the Product Owner and asking technical questions to understand the needs hidden in the requirements. For me, it's very exciting to understand why the requirements described in the User Story are needed, as this gives me the opportunity to identify alternative solutions that can delight the customers.
User Stories are generally formulated from a positive user perspective, for example, 'As an e-shop user, I want to be able to add products to a shopping cart, in order to…'. It gets interesting when you also play through other scenarios in your mind: How do we handle errors? Or what if the e-shop is used in a completely different way than imagined in the User Story? Maybe users don't want to buy anything in the e-shop, but rather steal other users' data or break the e-shop? Sometimes we intentionally write such 'Evil User Stories' that highlight the actions of attackers, to make potential vulnerabilities more visible.
The Sprint Planning itself goes very quickly. We had already discussed all the User Stories in the Backlog Refinement, and the Product Owner has already prioritized them, so now we just need to decide how many User Stories can fit into our 14-day Sprint.
After that, we often do a Task Planning (Task Breakdown), where we break down each User Story into tasks again. Each of these tasks should not take longer than a day to complete.
While we all in the team coordinate about which tasks have been completed and which we will complete by the next Daily Scrum, the focus is more on whether anything is preventing us from completing our tasks. Whether it's knowledge gaps, missing feedback from contacts, or a broken computer, we actively ask for support and, of course, offer it in return.
For me – as for my team colleagues – the Daily Scrum is also the perfect opportunity to respond to unforeseen events: implementing security updates, addressing questions or requirements from other teams, updating the software on live systems are just a few examples of unplanned incoming maintenance tasks. These can now be jointly assessed and scheduled.
The Sprint starts, and I independently choose a task from one of the high-priority User Stories of the Sprint and begin working. My tasks can be very diverse: programming, coordinating and consulting with colleagues, reviewing colleagues' code, testing, automating tests, documenting, maintaining existing software. Not least, Scrum also means a lot of communication, as it is described in the Agile Manifesto – 'Customer collaboration over contract negotiation'. If requirements suddenly change, the best approach is to talk about how we can make it possible together.
This independent yet very communicative work allows me to determine my own work rhythm and gives me the opportunity to actively shape the product and advise our customers, which is really appreciated. This is what makes my Scrum routine so enjoyable.
Before the Review, I take the opportunity to run through everything I want to show, and I also enjoy supporting my colleagues if they want to present their part of the Review in advance. This gives everyone the chance to become more confident in their presentation and public speaking skills.
While the features are being presented, I pay special attention to the feedback from all attendees: Have we understood the problems that the User Stories are supposed to solve, and have we found a suitable implementation? Have we overlooked any aspects or discovered new requirements? I then incorporate the new insights into new User Stories or note them down for a follow-up discussion with the Product Owner. Although security-related points are often not understood as technical requirements and therefore not considered for Reviews, from time to time, I show which security measures we have implemented in the product to raise awareness of security among colleagues and other stakeholders.
It's time to put aside the computer and focus on the team and our collaboration. I think about how well our processes and agreements have worked. I mention things that have gone well, but also those that we should improve.
The openness in the team ensures that over time, we get to know our strengths and weaknesses and can support each other in further developing our strengths and reducing our weaknesses, or compensating for them mutually.
The Scrum Master helps us define measures and schedule them firmly. With each Sprint, it becomes harder for me to pinpoint exactly what my individual contribution to the project was, and at the same time, it becomes much easier to recognize and rejoice in what we achieve together as a team.
