Scrum Puzzle #4
Most people seemed to get the concept that the team own the task board in the responses to Scrum Puzzle #3 but a few wanted to be helpful to management by allowing for some consistency or a key to make the board more understandable.
My approach is a much less forgiving. I think that the task board is only there for the team, and does not need to communicate anything to management or anyone else. There are other mechanisms in Scrum for management to know how the team is progressing and how they can help. The problem with giving in to this request, is that it opens the door for abuse, even from the most well intentioned managers.
If management want to understand the board, they might then want to ask questions about why there are so many bugs, or so few stories, or tasks that have been in progress for 3 days. They might think asking these questions is helping, but it is not. The most important thing management can do for an agile team is to trust them. All of these questions mean that management don’t trust that the team is doing the best they can. Once managers are viewing the task board, it might also start to be less transparent because the team want to look good to management and then the value of the task board is diminished.
I know this because I am a well intentioned software development manager of 4 agile teams, and I know that as soon as I start checking team task boards I have questions. As soon as I start asking those questions, I start interfering. Currently I don’t go to stand ups or look at team boards at all unless a team member specifically asks me for some advice or my perspective. I have one on ones with team members where they tell me what’s going on at a macro level and what I need to help with. I don’t need to manage the micro level within the sprint. The team take care of that themselves. It works much better for me and for the teams.
And now for Scrum Puzzle #4. I’m excited about this one because it’s not my puzzle. Someone enjoyed the puzzles so much they have mailed me their own puzzle to include. The puzzle is phrased in the first person as I have copied most of the text from an email.
“My team has been using story points to size stories and has a firm understanding of how this works for stories and seem to have fairly consistent sizing for stories in backlog grooming. However the team does not break down the tasks into hours and argue that scrum uses story points and not hours.
Sprint tasks are often in progress for 3 days or more. The daily Scrum therefore follows a predictable pattern: “This week I have been busy with this, and I am still busy with this and I don’t know if it will be finished this week but certainly not by tomorrow as this is a complex task.” The result is no burn down, and nobody knows if we are going to make the sprint goal or not. No other developers can get involved as nobody can explain exactly what is required to finish the story and therefore everyone works on separate stories.
My understanding is that adding up hours will give us clarity on if we have over committed or under committed and can then either add or remove stories. I feel the process of estimating tasks also aids the developers in understand the detail of what they are going to build. Much to the team’s dislike they started estimating hours on the tasks and then found the same problem they originally had before the days of scrum. Some developers thought a task was complex and due to their experience level they rated a task as 2 days while other developers rated the task as half a day. The consensus was half a day, but the team questions the logic of this approach and says: “What if another developer gets this task and it does actually take 2 days to do?” The team feels that any number they produce after adding the hours or days is inaccurate and therefore meaningless.”
I’ll offer my view in the next post, but for now what do the rest of you think the right thing to do here is?