Skip to content

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?

7 Comments Post a comment
  1. I’m not fond of the breakdown of stories into tasks. The reason is that you can get most of the tasks done, and no stories. As far as I know, we invented the idea on the first XP project and the best teams have now moved well past it.

    The thing to do in this situation, in my opinion, is to have smaller stories. One day, two days at most.

    It doesn’t really matter if they are estimated in points, days, or gummi bears. If I had it to do all over again, I wouldn’t introduce estimation at all. What matters is that stories are small and of roughly uniform size.

    October 29, 2011
  2. My immediate response is that this has nothing to do with hours. This is about task breakdown. The team should be making an attempt at SP2 and breaking the work down into tasks that take less than a day. You don’t need to know anything about the number of hours – but if all tasks are less than a day you can get a feel for progress or lack thereof.

    Equivalently the team should understand the work coming out of SP1 & 2 so that no matter who is doing the work – another developer could pick up any of the other tasks on the story and continue the story or help them complete it.

    Some teams hate doing a full breakdown up front. But at the barest minimum doing a full breakdown at the start of story should generate a list of tasks that all take less than a day and any other developer could read the tasks and pick them up themselves as they are meanful to the whole team – not just the way one developer operates.

    I’ve never done hour estimates with my teams. And I’d hesitate to as I don’t see the value – if your tasks are showing progress on a daily basis. We measure stories as that is what is valuable to the end customer. And measuring tasks / hours might generate other behaviours if people start to question them or measure them.

    My 2c 🙂

    October 29, 2011
  3. Mark #

    Personally, I don’t think the issue is the breakdown of the stories into tasks. The issue is the waste in estimating them. Estimation is guestimation and it is therefore vague by definition. To me, tasks are merely there to represent in a visual way what needs to be tackled in order to get XYZ story ‘done’. Whether they are relatively complex or trivial, small, medium or large, shouldn’t matter. If they cannot get ‘done’ in a relatively small amount of time (day or 2 in some cases), then the actual story is probably too big and would need to be split up.

    @Ron: I’m interested in your final statements regarding not estimating at all. Are you suggesting a possibly leaner, less prescriptive approach ala Kanban? Rightly or wrongly, in deadline driven business, managers love and will always use the “when can I have feature ABC” line.

    October 31, 2011
  4. Mark, I don’t know what managers love and what they will always do. I suspect not all managers are the same in those matters. But no matter what managers love and will do, lmost the entire exercise about estimation is a waste of time, and it leads to abuse far too often — I want to say “nearly always”.

    What a good manager would do would be to observe the team’s ability to build things, and predict outcomes based on those observations. A good manager would not attempt to improve the outcome by making more optimistic predictions: that’s like trying to improve the weather by saying it will be warm and sunny tomorrow.

    Then, having based predictions on observation, the good manager would go on to help the team figure out what is in their way, and would help them remove the obstacles and waste. This would improve the ability to build things, improve the observed data, and thus improve the predictions.

    October 31, 2011
  5. In my experience teams are much better at estimating small tasks than large tasks, something between 15m and 2h. The issue I’ve seen with having either no tasks or very large tasks is that when someone gets behind, it’s a lot easier to fudge the numbers. When I’m working on a story that the team thinks might take a couple of days to complete and I’m down a rabbit hole all morning, the reaction is always “oh we’ve still got a day and a half to get back on track”. That’s just lying to yourself and the team. I’ve collected some data on a few teams (small sample size) and have found that the estimates are mostly on target and not wildly off in either direction.

    Unless you have an especially high functioning team, my fear with avoiding tasks or having very large tasks is that the team won’t try to push their perceived limits and will just commit to the same number of points iteration after iteration letting the work expand to fill the time available.

    October 31, 2011
  6. I have a feeling that estimation is an example of a behaviour which doesn’t scale down well. Estimation makes sense (maybe) at the level of commitment of major effort.

    Your desire to do a project or maybe even a feature can be strongly influenced by the size of the thing. At that level it is possible to calculate ROI and make a decision.

    But like gravity, when you scale it down to the quantum level, it makes a lot less sense. What are you trying to use estimation as a means to do exactly? Is it whether or not this particular story has enough decomposition of tasks? To predict whether this story is likely to be finished this sprint? Getting the team to commit to more stuff? To track effort expended by a particular person or on a particular story? To “force” the team to engage in collaborative design?

    I get the feeling that we’re reaching for the inappropriate tool. Rather try to find the root cause for your need for estimates at such a granular level. You’re likely to find that estimates provide an imperfect match for what your real need is.

    I suspect almost all your needs can be fulfilled (including increasing the output of the team) by working on smaller stories. You know what else it does? Completely removes the need for estimating even in story points. (Another concept whose time has come…)

    November 1, 2011

Trackbacks & Pingbacks

  1. Scrum Puzzle #5 | Coaching teams to do better scrum

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: