ANSWER

This question is likely rooted in a misunderstanding of what agile development is all about.  Agile project teams are intended to be assembled for specific projects. Once a certain amount of product planning, backlog planning, and sprint planning takes place, the first sprint kicks off.  From that point on, the goal of the agile team is to deliver incremental user value at the end of each sprint and to maximize the velocity at which the team delivers such value (Velocity is just a fancy term for the number of Story Points completed during a sprint, and Story Points are the unit of measure used to size user stories relative to each other). 

None of this means that the velocity incorporates all costs associated with developing the features defined by the user stories.  Overhead still exists within agile teams.  In fact, story points don’t track absolute hours at all.  They are intended to show the relative size and complexity of user stories for prioritization and sprint planning purposes.

Typically Project Management and Product Management time is lumped into overhead costs.  One major reason for this is that much of the work done by these roles cannot map one to one with user stories.  There is a lot of project management work and product management work that occurs which never results in value to the user.  For example, a product manager may document or lead the effort to create a series of user stories that, once estimated, end up being prioritized out of existence.  Perhaps the decision is made that there isn’t enough value in the user stories to have them developed. So this is one example where the time spent by people who work on or with the agile project team isn’t tracked by a user story.

So back to our original question, should distinct user stories be created for maintenance and support.  The short answer is no.  Once a system or application is developed, there will continue to be hardware and infrastructure management that needs to occur. Someone needs to monitor server loads, bring new virtual servers online when system load rises to a point where server degradation begins to occur, etc.

The slightly longer answer is that while user stories should never be created solely for system support or maintenance, support and maintenance tasks can sometimes be sized into new user stories when it makes sense.   If it’s known in advance that a feature defined within a user story is going to require a significant amount of infrastructure to support the new functionality, then the time require to set up and configure new servers should be included in the user story estimate.  Of course, it may make sense to distribute this time over several user stories that require the new back end resources.  So, really it depends on whether the work is a result of the user story itself.

It’s also worth noting that refactoring is a natural and necessary part of agile development.  Refactoring describes the act of restructuring the internal structure of existing code without impacting the external functions of the system as viewed by the user.  Refactoring may be needed to improve non-functional aspects of a system such as response times, or refactoring may be required to support a new feature that can’t be supported with the current architectural structure.  In agile projects, refactoring is expected and should be planned for.  The incremental cost of refactoring should be spread across the impacted user stories whenever possible.  User stories contain acceptance tests that need to be retested once the refactoring occurs to ensure that the existing functionality hasn’t been broken.