TL's guide to an (almost) perfect burndown

Written by: Pragyakar Joshi , Lead Engineer

An ‘ideal’ burndown chart defined

If you are a team leader (TL) in a team that follows a scrum based workflow, you probably have a burndown chart logged in your system. The insights it provides help determine a sprint’s work progression and forecast any possible adjustments required to meet the sprint’s goals.

An ‘ideal’ burndown chart follows the planned trajectory, but as the name suggests, it is based on an ‘ideal’ assumption that things will go according to plan. However, that is not always the case, is it?

Despite this uncertainty, as agile practitioners, we can still try to achieve improved outcomes by embracing a culture of continuous improvement. In this regard, there are certain patterns exhibited by scrum teams that team managers and team leads need to watch out for.

This blog tries to cover a few of the patterns based on my experience, which helped my team achieve an (almost) perfect burndown chart that went from Exhibit A to Exhibit B in a couple of sprints.

The obvious answers addressed

Firstly, let’s make a note of the fundamental answers that every agile practitioner will emphasize:

1. Starting with a clear sprint goal to ensure everyone knows what is to be achieved.
2. Effective sprint planning to allocate tasks more effectively .
3. Scrum ceremonies to keep the team aligned.
4. Monitoring progress to track achievements and consider any blockers.

While all of these points are valid answers, these are just the basic guidelines. A truly dynamic scrum team has to embrace the dynamic nature of the project and the team.

The patterns observed

There are certain patterns exhibited by teams that I’m pretty sure everyone can relate to while working in a scrum team. Recognizing and understanding these patterns can offer valuable insights into the challenges and opportunities, fostering more effective teamwork and project outcomes.

Pattern #1: Master of one

One of the most common patterns emerges when one team member possesses extensive knowledge in a particular area of the system or codebase. They know everything there is to know about their area of expertise, making them highly productive and dependable in that particular domain.

While their expertise can be a great asset to the team, this pattern can lead to a heavy reliance on them for certain domain specific decisions. Consequently, this might hinder collaboration as they are fixated on their domain, and tend to avoid tickets that are out of their area of expertise.

An easy way to break this pattern is to diversify the domain of the tickets assigned to the individual, which could be a different module within the system or a different area of the codebase. While doing that, it is also important to acknowledge their expertise.

Pattern #2: Own it to show it

Contrary to pattern #1, certain team members tend to take tasks that are thinly spread throughout the project. They have a tendency to prefer lightweight tasks and avoid complicated ones. While having an idea of the entire system/codebase is good, this pattern may lead to a lack of sense of ownership in the long run.

An easy solution to this can be to assign something that they can take full ownership of— could be a feature, a user story or even an entire module. The goal is to cultivate a sense of genuine ownership.

Pattern #3: Going all in

Imagine this, you’re on the final few days of the sprint, all set to wrap things up, but as you’re getting things ready, you receive a massive pull request with changes in 50 files and 10000 lines of code. I’m pretty sure it wasn’t hard to imagine since it’s a pretty common pattern that occurs quite often.

There could be many reasons for this but let’s focus on the impacts. This tendency to work in isolation and present everything all at once not only restricts individual progress, but also slows down the team’s progress. The post pull request phase of review, feedback and improvement is hindered as the reviewer will also find it very difficult to go through the massive chunk of code in a short duration of time.

As engineers, it is natural to be hesitant to submit work before they think it’s ready for review. However, in order to foster a culture of team collaboration, it’s important to rectify this pattern. While creating a draft pull request is a quick solution, breaking down a huge task into smaller manageable tasks during the Sprint Planning phase can help avoid this pattern. Receiving early review provides the team with an opportunity to learn from each other’s work, as well as get enough leg room to work on feedback.

Pattern #4: Scrum-bling with issues

Product ownership plays a vital role in determining the outcomes of a sprint. Fluctuating scope and requirements leads to risks and challenges for the team. Having much to work on or having less to work on can both be considered bad.

Thus, it is important to bring up such inconsistencies to the manager. It is the responsibility of the scrum master and the tech lead to address this issue. Using historical data to address this issue and coming up with a plan to attain consistent workload will certainly help attain a consistent burndown.

Conclusion

Heavy reliance on a team member, gravitating towards lightweight tasks, inconsistent code submissions and unstable product ownership are just some of the common patterns that teams have to rectify based on the situation. Recognizing and understanding these common patterns can provide valuable insights for fostering effective teamwork and consistent project outcomes.

"In Scrum, embracing change is not just a principle; it's a practice. Adaptability is the heartbeat of progress, and the agility to welcome change ensures that every sprint moves us closer to excellence."

The above outcome was achieved after multiple sprints, which goes to show that addressing these patterns is not a one-time fix. Working on a scrum based approach is an ongoing process. Finally, it is also essential to work on these improvements with professionalism, open communication, and a shared commitment to continuous growth.