Scrum is touted as one of the modern new techniques that can get rid of all the problems that people have faced with earlier techniques such as Waterfall (and if one goes by correct theory, Scrum is primarily a Project Management technique, not a broad Project Development methodology. However for those people who are passionate towards Scrum, Scrum has always seemed like a solution that can work for most projects. However, people do find that their burndown charts don’t resemble the idea, with the effort needed not trending down to 0 at the end of the Sprint cycle, instead, it happens that the overall effort required remains at the end of the cycle.
This trend can be very frustrating; if you have a team with around 4 developers, and if you find that all of them have some effort pending at the end of the cycle, it could mean that all of them are just there, but not fully. Instead, there are tasks that you need to call out in the end Sprint review, and they need to be carried over to the next Sprint. Now, this would be fine and part of the normal process if the ScrumMaster is able to do a proper diagnosis of why this happened (and there are multiple reasons for why this could have happened), but when at the end, there is no proper reason, it can get very frustrating for the ScrumMaster.
It feels equally problematic when the ScrumMaster has to depend only on the burndown charts for getting the exact status; since the burndown chart is not designed for getting into the required depth (at this point the ScrumMaster would want to get into exact status of various items and compare the current status of all the tasks with the desired level of completion), and if the ScrumMaster does this often enough, they will lose interest in the Burndown chart. A lot of ScrumMasters don’t want to get into the detailed task level status, since it can be tough to then do a root level analysis of which of the tasks were delayed because of reasons that could be prevented.
What I have found (based on some of the teams that I worked with, as well as some friends who were also doing the ScrumMaster bit), we used the Burndown chart as a good indicator for showing to the team how well they are doing (including whether they were running behind and needed to check whether their velocity was good enough); for actual task tracking, we used various scheduling tools (or even used Excel as a way of tracking); it seemed a bit more effort intensive way of tracking, but worked properly and gave us a much better way of control.
