ScrumMasters, Don't Touch That Task Board!
26 March 2014
ScrumMasters, please don’t touch the task board. It (and the items on it) do not belong to you. The task board belongs to the development team.
Team members place items on the board, they move items across the board, and they remove items from the board. The only time the ScrumMaster should touch the task board is when someone on the team requests it, or after the SM asks for and receives permission from the team.
The reason for this is ownership. In Scrum we ask the team to be accountable for delivering working software each sprint. Part of ensuring that the team truly accepts this responsibility is giving them ownership of the work. And part of giving them ownership of the work means that they should also own the means for tracking their progress. We all know how satisfying it is to cross something off our to-do list. How would you feel if someone took that from you?
And this doesn’t limit itself to the task board.
In a CSPO class the other day, while the class was on a break, I was prepping for a prioritization game by adding estimates to their user stories. These stories were up on one wall, in areas denoted by calendar quarters. The class had spent the last hour writing user stories, writing acceptance criteria, splitting stories, and taking their first cut at prioritizing them. And now here I was writing gross level estimates on them as they filed back into the room.
“She is WRITING on OUR STORIES!” said one of the attendees. An unpleasant murmuring started around the room.
Fortunately this became a teachable moment, and not the butt-kicking I thought might be coming instead.
This group OWNED those stories. They’d sweated over them, put their heart into them, were proud of them. My attempt to simulate the team’s estimation of each story was overshadowed by the idea that as the leader, I had “taken” their work and was putting my own mark on it. I had broken my own rule and did not think to ask their permission to do so, because these were product owners, and not the development team members.
Lesson learned. It doesn’t matter who it is – if they define the work, document it, sort it, and schedule it, they take ownership of it. And I had better not touch it.
Current rating: 4 (5 ratings)