Introducing a burndown chart
I've recently joined an existing Scrum team, who've been using Scrum for about a year. We've made good progress in the 4 sprints we've been working together. One thing there seems to be a bit of resistance from a couple of team members who have been around longer is team-level metrics - they got rid of an hours burndown chart a few months ago and their velocity was initially hard to gauge when I joined - there was no planned vs actual check at the end of each sprint for example, and no consequence for PBIs constantly rolling over. I see metrics as an important part of the inspect and adapt loop, in measuring our improvement initiatives and giving transparency. I would like to introduce a story burndown chart next sprint to help us visualise our Done work. How would you recommend introducing this to the team? In some schools of thought, something like a burndown or CFD is an important information radiator that a Scrum team should use without question. My thinking is rather than to just do it, to raise it as a suggestion at our next Retrospective, explaining that it will help us see how we're tracking during the sprint. Thoughts?
I am assuming that you are a Scrum Master serving this team. Apologies if my assumption is incorrect.
I think that introducing and discussing it at your next retrospective is a good idea - focus on the potential improvements and benefits with using and maintaining a Sprint Burndown Chart (transparency, visual representation of work, placing focus on work that meets DoD). In my opinion, you are correct in your belief that a burndown (or burnup) chart is a critical information radiator that should be used for all Scrum efforts.
My only question is in regards to any existing visual boards. How is your team currently viewing their work? What do they use to help their discussions at their Daily Scrums? If they have a visual representation of their Sprint Backlog, it should be quite evident when items within a sprint are lagging behind and need greater attention from the team (i.e. - swarming) in order to finish them within the sprint.
Yes, I am the Scrum Master for the team. I know a burndown is not an official part of the Scrum guide so its not something I should 'enforce', rather it is suggested that its a good idea. This is why introducing it and discussing at retro seems like the right route to go. Re. existing visual boards, when I joined the team, they didn't use any visualisation to help them with their Daily Scrums. We have since introduced a physical task board, which has helped a lot. This is fine, but my observation is there's still that false sense of security of getting lots of tasks done and not enough visualisation on overall user story completion.
Maybe, you can ask them how confident they are in their way to reach the sprint goal and what evidence can they use to give this level of confidence ?
One thing that I have found beneficial when observing the team or thinking of ideas or practices to introduce to them, is to have them respond to the three Scrum principles (Transparency, Inspection, Adaptation) or the five Scrum values (Focus, Openness, Respect, Courage, Commitment).
I think one possible cause for your issue is the team's focus on "tasks", and not complete stories. You say that the team has introduced a physical task board - I would change this to only track stories and not tasks. The team is perfectly within their right to define and allocate story tasks as needed, but nothing really matters until the story is delivered, right? A team can be finished with 90% of their defined tasks, and yet not have a single story meet their Definition of Done.
Keep in mind that as the Scrum Master, your only real authority is around Scrum. If the team is focused on tasks and not story completion, then they are not following Scrum, and it falls on you to change things so that they are.
As much as you want to "convince" them and have them take ownership of the decision to use a burndown/burnup chart, it does not seem negotiable to me, unless the team not only has another way to provide visibility, openness, and transparency into their sprint work, but also a way to adhere to their forecast of accepted sprint work.
Good luck.
I believe Timothy is right to put the focus, at least in the first instance, on boards rather than burn-downs. If the team can see where waste is being incurred on the board itself, and wish to take steps towards better practice and with improved transparency, then that is the point when tools like burn-downs can be suggested.