Working in Agile Environments: The Sprint is Not Just About You

The sprint is not just about the stories you deliver, and your commitment is not only about you.

By committing to the stories that make up the sprint, it is crucial to consider the time and mental effort required for other phases of the development cycle.

In an agile environment, we have many meetings and processes that go beyond individual story development, whether we like it or not.

Let's consider two scenarios, both with 2-week sprints and a commitment of 8 points.

Scenario 1: The sprint has just started, and you have a superficial understanding of what needs to be done in the story you committed to because you didn't fully understand the acceptance criteria. You chose not to ask, thinking things would become clearer during development.

When you open the code, you spend an hour trying to find the file with the necessary component for the change and another two hours understanding how the components communicate.

After a lunch break, afternoon meetings, and, with luck, another hour of coding, the workday ends.

Days pass, and you get stuck, a common occurrence in our field. However, instead of seeking help from a colleague (whether through "rubber ducking" or pair programming), you feel like you have time, and you'll surely figure out the solution on your own. After all, there's still more than a week until the end of the sprint, so you don't communicate your difficulty to the rest of the team and decide that the best thing to do is to think about other things (sometimes it is), and you end up getting lost on the world wide web without solving the problem.

Three days before the end of the sprint, you still haven't understood the acceptance criteria, so you ask the Product Owner (PO) about the business meaning. He explains that you believe you understand and start implementing. However, you are interrupted by an afternoon refinement meeting in which, without understanding which stories need refinement, you adopt a passive stance, not contributing to the discussion.

One day before the end of the sprint, your Scrum Master is concerned, your story is crucial for the sprint goal, you are a bit tense, just submitted the PR for review. The result? Four open tasks, 11 comments, and an implementation that needs to be redone due to a misunderstanding of the business rule. Definitely not going to make it in time.

On the last day of the sprint, the sprint goal is not achieved.

(Certainly, it may seem absurd, but it happens more often than one might imagine.)

Scenario 2: Same 8 points, you have clarity on what needs to be done in the story. In fact, you've already written some personal notes to assist in the implementation, a result of the time invested in refinements. The first hours of the day go well; near lunchtime, you encounter an unforeseen problem and request a "rubber ducking" session with a colleague, which fortunately resolves the issue.

At the end of the week, your code is implemented.

On Thursday, you open a Pull Request (PR) and request reviews from colleagues. While waiting, you review backlog stories that need refinement. At the end of the day, you help a colleague solve a technical problem related to the business rule and finish the day.

On Friday, colleagues leave comments on your story. You realize you forgot to remove an unused parameter and that your new function can be optimized. You work on these improvements and send the new PR. Your colleagues are agile, and the merge is done before lunch.

There is still a week left in the sprint. Your PR is integrated, and you can actively dedicate yourself to helping other colleagues. There is time in the schedule and, most importantly, mental space to actively participate in meetings.

You review colleagues' PRs and take the opportunity to study a technical topic that you recognize as a weak point. On Friday, before the end of the sprint, neither you nor your team are stressed. Everything has been delivered.

This scenario, not as fictional as it may seem, illustrates how a software developer's work goes beyond delivering story points. It involves commitment and participation in the entire development cycle, assisting colleagues, and learning business rules. Time management is crucial, and realizing that the sprint is more than an individual commitment is crucial.

My suggestion is to learn time management, commit to stories considering refinements, presentations, and PR reviews, and, most importantly, understand that these things are as important as the points you deliver.