The “Catchall” story
So an interesting topic came up in a retrospective last week, one that has come up on past teams as well and I’m still unsure of the best answer for it. Example: team members get hit up for a production question or something else that isn’t a story in the backlog and spend a chunk of time working on it. This interferes with their other work and maybe they don’t get as much done as they committed as a result. Now they want to account for those types of things with a special catchall story in the backlog so they can account for that time and track back to it. What’s wrong with this picture?
So trying to fulfill my role as the ScrumMaster but also my coaching role, I dug into this a bit more. Why are these things not in stories? Are they dependencies? Should they be in bugs? Are they frequent? Who else is having the same problem? These were just some of the questions I asked. Turns out these were somewhat dependencies, somewhat just the expertise the person had. They might have been other teams’ stories and no, they shouldn’t be in bugs. It seems that most of the team runs into these things from time to time. And in this team time it equates to roughly 3 points per iteration.
So, the Scrum answer I have in my mind is, “No, we shouldn’t put in a catchall story to account for this work. We do not need to account for every hour of our time, as we are not expected to be productive 40 hours per week, every week. These things are adding value but not directly to any of our stories or features, and a catchall story would not show us anything really. We couldn’t track it back to anything on the Product Owners’ priorities, if we could the time should be accounted for elsewhere in a story. Also, we should be accounting for this in our sprint planning and not committing to as much. By adding a catchall story, we’re not really seeing the problem is in our estimation and commitment and we’re over-committing if a few questions are making us fail to meet our sprint goals.”
What I really said was, “How do you think adding a catchall story will add value and solve this problem?” It turns out the team was thinking in the correct way but even though I pointed out that by adding a three-point story or taking three points off our velocity/capacity when committing would yield the same result, they still felt very strongly about adding the story to the iteration, pointing out that it would allow us transparency to see how often these things were happening and if it was really a bigger problem than just a few isolated incidents.
So we are going to try it out for a sprint or two. Quite honestly I’m not a huge fan of the idea, but I’m not vehemently against it. I can see the transparency angle and think it will be a good experiment. Then again, there are always going to be things that do not fit into a story or task (e.g. emails…) and it’s not useful to track every last-minute back to something unless you’re capitalizing everything, but that’s another story of if we’re over-scheduling our teams and they feel the need to do so.
In conclusion, we’re going to try it and see what results it yields. If it’s a bad idea, well at least we have timeboxed it and will fail fast. What do others tell their teams about this type of quandry? What results have you seen from catchall stories?