Suppose you’re posed with the following situation (based on a true story, but names and places have been changed to protect the innocent):

Our team is currently engaged in some refactoring stories, and I have a question about how to properly handle the size and placement of these tasks. We’ve created six stories specifically for this purpose, and they are currently being worked on in a local development environment. These stories won’t be implemented until the next version of the software, which we are not yet focused on.

We’ve already estimated the size of these stories, but if we incorporate them into the current sprint and then remove them later (once the coding is completed), it will distort the numbers for the sprint, because the stories cannot be tested yet. Is there a way we can properly acknowledge this work while making it clear that these stories won’t be implemented for a few sprints?

Here’s what we’ve came up with so far: The developer can create smaller tasks related to the story and include them in the current sprint, without actually moving the story itself into the sprint. This way, the points for the story won’t be part of the sprint plan.

Once the tasks are completed and the story is ready to be implemented in a future version, we can include the points in the sprint at that time.

Okay, so I had a huge jumble of feelings when I first read about this situation. And let me start by saying, if this describes your situation, I feel for you! It’s a bit of a mess. And I do want to dissect this, and offer my best advice. But first, I want to give you, my readers, a chance to ponder this situation, and consider how you would respond.

I’ll kick things off with one of the first things I noticed, though… The key phrase “refactoring stories” made a few alarm bells go off in my head. Why?

Well, just last week I wrote about the idea that the purpose of a user story is to spark a discussion about the user’s needs and how to solve them.

Refactoring, however, has nothing (directly) to do with addressing a user’s needs. By definition, it does not change the software’s behavior.

Taken together this means that you cannot have a user story about refactoring. That’s the first red flag I saw.

There are many others, too. I’ll address them in an upcoming message (or ten).

Until then, what jumps out at you in this situation? How would you respond to this person seeking honest help?