Chasing The Perfect Burndown
The perfect burndown. Many of us at one point in time have chased this ethereal goal. As I coach a team on cycle time and value streams and why a good looking burndown is important, I find myself chasing the same ethereal goal. It’s not the first time the team and I converse about burndown’s and I keep telling myself “they” just don’t get it. The team shares with me that it can’t accept stories until the end of our three week sprint because that is when they deploy them to production. So I come up with the “brilliant” idea of closing our stories when they are completed and just have one catch-all deployment story at the end of the sprint. I think that will get the teams burndown to “look” better. By the end of the meeting, we do not reach any definitive next steps and I sense they feel that the solutions we discussed mean more work for them.
Cliff Diving
The more I think about the meeting the more mortified I become. In my quest for the perfect burndown I had lost sight of why burndowns are important. In this team’s case, the quest for the perfect burndown was driven by a desire to address previous sprints’ burndown trends that exhibited as cliff dives. A cliff dive is what happens when a team accepts a majority of their work the last day of a sprint. This anti-pattern is risky due to the potential for last minute sprint surprises causing stories to not be completed in the current sprint and get pushed out into the next sprint. It can also be an indicator that the team is not keeping stories up to date in the Scrum tool and updating them only at the end of the sprint. This can be addressed in the team stand up in real time by the scrum master. I have found that speaking into what motivates a team has been very powerful in helping teams own the updating of their stories in real time. The key is demonstrating to them how maintaining the scrum board cuts down on meetings and empowers the team to collaborate more effectively . The cliff dive is a burndown anti-pattern that indicates an opportunity to improve cycle time and deliver value to customers more effectively. Looking good is not why we chase perfect burndowns with our teams. Leveraging burndowns to discuss with our teams how we can deliver value quicker, with higher quality and less effort is the secret sauce that we are after. It’s so easy to forget and chase after looking good. What was I to do ?
Owning Your Mistakes
I put my ego to the side and used this as an opportunity to model taking ownership. The next day I admitted to the team that my coaching was off and explained to them why. I shared with them that looking good was not the reason we strive for pretty burndowns and that our customers don’t care what our burndowns look like. They do care, however about the value we deliver, it’s quality and speed. I also reflected on what a Quality Engineering manager shared in our earlier meeting about testing automation and the ability of the team to deploy in real time without deployment support of Ops. The team and I discussed what percentage of our stories require manual deployment at the end of the sprint vs. effort to automate. Quality Engineering shared they would start looking into how to decouple the teams dependency on manual Operations deployment. The team started percolating ideas on how it could deliver stories to production quicker and minimize the delay from the time work was completed to when it was released into production. Though there was no magical silver bullet revealed in the meeting, I felt a positive shift had taken place within the team. The concepts of value streams and cycle time had become more tangible and better understood. I had modeled that it was ok to own making a mistake in front of the team and that when one does, good conversations can happen. Interesting enough our next sprint’s burndown, while not perfect, was one of our best ! Coincidence ? I like to to think that our conversations helped 🙂
What would you have done ?
