During initial sprint planning, stories correspond to user features, and typically follow a
As a [user type]
I can [some action]
So that [some benefit]
structure.
Its important to keep the stories focused on features, rather than on tasks; because we need the users / product owner to be able to decide which stories to add or remove. (A user cannot decide which tasks to add or remove, because the dependancies aren’t obvious).
However, during development of a particular story, you will often come across an area of the code that needs to be refactored. A classic example is the case of removal of duplication; where as the design has evolved we discover additional areas of common functionality.
It can be tempting to attempt to work this refactoring into the current story, and if the refactoring is relatively small, this is a good idea.
However, in many cases the refactoring is too large to do without increasing the complexity of the story so much that it might not get finished in the current sprint.
This is the time to create a new “technical story”, which encompasses the refactoring (and perhaps any related work).
Its important that this block of work becomes a story to increase its visibility to the team, and to the product owner. I’ve found that other team members always have useful input (hey, area Y of the team needs that too), and the product owner gets to prioritise the refactoring along with other stories.
This also makes plain to all the stakeholders why technical debt is increasing – if too many of these technical stories have been neglected in favour of new features.