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?
agile catch-all catchall catchall story coaching estimate padding over commitment over-scheduling productivity scrum velocity
5 Responses
My team has user stories with story points for most work in the “keeping the system running” category. Like, app server update, database update, changing some webservice technology, … The problem with this: The end users do not care about any of that. “As a user, I want the system to continue to run like it always had” is not a user story. Everybody accepts that as given.
I am not happy with it. Our velocity does not reflect user valued features anymore. When we finish x story points in a two week iterateration, x/2 story points might just be maintainance. But it looks like the team delivered x.
This leads to further problems. Like: “We can not invite end users to our sprint review. They would be bored by all the technical user stories.”
I mention this issue every now and then, but the PO insists on doing it that way, and the team is OK with it. So far I was not able to convince them that this is wrong. Because, “Our velocity would be lower!!! OMG!!!” – Even though our current x is (kind of) “cheated”.
I agree with the frustration, David. I like the idea that Allison mentioned – track the work but not in velocity. It’s true, ideally velocity should only be used for value delivery. Is there a perfect answer? Not that I can think of right now, but I will continue experimenting. Your thoughts are spot on and make a great point. Thanks for weighing in.
Ooh, interesting situation. I had a team that often had to respond to production issues, and they tracked ‘production support hours,’ which were graphed as a line that trended upward during the sprint. They had done that for many sprints before I became the Scrum Master, and it seemed like no one outside of the team cared that the team had this unpredictable work interrupt their plans. We stopped tracking the time spent for answering questions and learned to bring in the ‘right’ amount of work each sprint, and if an issue came in that required coding and testing, we defined a story and sized it. It seemed to provide better visibility to our stakeholders about what work the team was needed for and let them prioritize what the focus should be as it was changing during the sprint.
I think it’s cool that your team is wanting to add visibility to their work. I don’t think I would size miscellaneous work that is not delivering value; I am already imagining that when forecasting when a release will end, you’ll have to use the team’s velocity minus 3 [their miscellaneous work size] rather than be able to just use their velocity. Hopefully by seeing the work, the team can get to the conversation of “how do we reduce this work or deliver more value with it?”
Thanks for the comment, Allison. I’m hoping this will help to increase transparency too as it did with your team. I also hope it can help the team to come up with better estimates based on their true velocity minus these issues.
I want to say I talked about this with my team and by using this catchall story for a few sprints, we can better see trends for what “extra” non-sprint documented work is coming in. We plan on doing that for a bit and then no longer using the story but adjusting our velocity by the average effort in points we’ve been spending. Trying not to outright convert points into time, but that’s a hard habit for some of my team members to break. Thanks for the great conversation everyone!