I’ve often read guides and best practices directed at Scrum Masters to help them excel at their job, but most Agile teams often don’t have a clear understanding of what to expect and how to maximize the value of their Scrum Master. Are you asking enough from them? When should they be involved? Do you know how to challenge them or ask for adjustments to their style?
In essence, the Scrum Master is a servant leader of the team, pushing people up to reach their potential and clearing any roadblocks that may prevent them from getting their job done. It is ideal for the team to feel that they are constantly improving, inspecting and adapting. If you’re not doing this iteratively, then something needs to change, and the Scrum Master needs to step into action.
In this blog series, I will provide some handy tools for any team member to make good use of their Scrum Master. This will not only help developers, QAs, and POs, but also allow them to provide coaching to their Scrum Master. Remember that this role comes with leadership without authority, and great leaders need feedback, too.
What’s with these graphs and reports? Believe it or not, reports are extremely useful and contain priceless information about the team’s overall health. They are not just metric reports meant for management alone; with good interpretation, you, too, can get involved and learn from them.
If you do not understand a report, that’s your first call for help from your Scrum Master. They should be able to tell you what the basic Agile reports are used for. Here are 4 good ones to keep in mind:
A. Burndown Chart
One of the most used reports in Scrum is the Sprint burndown chart, which gives a clear and concise view of how the team is set up to meet their committed goal. This chart measures remaining tasks over the Sprint days, as well as providing insight over how the team is spending their time, what days were tough, if they overcommitted, or if they underestimated the hours it would take to accomplish tasks.
A healthy team should check the burndown chart regularly throughout the Sprint, and your Scrum Master should be on the lookout for sharp peaks and valleys. If the team is properly tracking tasks, they become predictable and can give your Scrum Master the superpower of clairvoyance to foresee idle work or risks and address them before they actually happen.
B. Release Burndown
This graphic is a higher-level view of how the project, program increment or epics are progressing. We should be able to see a steady reduction of remaining work while the team keeps providing completed work, right? However, in the real world, things change. Some of these changes are reflected as “scope creep,” which is merely added, unplanned work that sometimes the team needs to take into its backlog. This happens often, but the Scrum Master can provide valuable feedback to management on how this may be affecting their overall product vision.
Anyone can raise their hand and say, ‘’We’re taking in too many last minute requests,’’ but your Scrum Master can utilize the release burndown data to demonstrate the actual impact of this. There’s no better way to protect the team than protecting the delivery value with hard data.
So, the next time you discuss scope creep in a retrospective, ask your Scrum Master to review the release/epic burndown with the team.
Ahh, velocity. Sometimes used as the holy grail number, the key to commitment, the metric to draw a finish line for our Agile projects. More often than not, velocity is looked at from outside of the team; maybe management wants to know how fast they’re going to get a feature, or maybe a scaled environment uses it to see which team is ‘doing better’ by comparing numbers. But this is not what velocity is meant for!
Velocity is a metric that provides input on the average points the team usually delivers on a Sprint. Product owners can ask for the Scrum Master to constantly monitor this chart; future planned Sprints may change commitment if the velocity is shifting. Consistency is key here. If the team’s velocity changes drastically every Sprint, there might be some adjustment needed on estimations or commitment, or some behavior within the members that could be causing this, but this can only be done by regular inspection. It is normal to see variance while the team matures, but you should strive for a regular rhythm and cadence.
Team members can ask the Scrum Master how a new work model or a different approach affected the velocity; something may seem like a good idea when inspecting/adapting, but it is important to complete the loop and show how a new strategy looks on the data side.
Last but not least, changes to the team such as team members being added or leaving, or changes in structure, leaders, new technologies or architecture trends, often affect velocity. Expecting to keep the same velocity throughout these changes may affect the delivery vs. commitment.
I’ve worked with Agile teams that have had to deal with delivering stories along with production support. Now, there are dozens of metrics you can track for defects, but there’s a single one I recommend for teams to focus on (and let others focus on the rest): how much are we building vs. fixing?
There’s usually a certain amount of effort your team might end up investing in fixing, but this is a hard one to estimate. How can you predict how much impact there’s going to be in the next Sprint? Keeping track of how many story points were delivered, and how many bugs were fixed, is a good way to provide an approximation of how much the team should commit to in order to ensure they will have the capacity to fix things if something breaks. It is better to be prepared to jump on an issue than to commit to the fullest and then have to drop something because we expected no production issues.
My advice to Agile teams: ask your Scrum Master about these reports. They will give you a strong base and evidence showing why you are succeeding or which areas can give you tons on improvement with even slight adjustments. Regardless of metrics, your Scrum Master should be able to transparently tell the story behind the sprint to all team members and stakeholders. Remember, Scrum Masters are there to coach you. It’s no use if this only happens at the end or beginning of a Sprint. Every day is an opportunity to ask, ‘’Hey, can you show us how we are doing?’’