A TechnicalStory is used to capture any requirement that is technical in nature.
Techncial stories are often used to capture NonFunctionalRequirements, but there are some dangers in this, because while it is important to include technical requirements, it is also very important to avoid over-engineering.
We have seen projects struggle because there was insufficient consideration of technical stories, but the reverse, of over-engineering, is a much more common and much more painful mode of failure.
In one organization we know of, a team of 20 people spent three years building infrastructure that was never used in any application, this is an extreme, but not at all uncommon case.
In order to avoid such unproductive over-engineering it is vital that technical stories must be capable of being evaluated on the same basis as regular [:Story: stories]
Any commercial software project will have some constraints on time and money and so decisions on the scope of a project to fit into these constraints will always be an important part of any project. This means that there has to be some way to evaluate the relative merits of NonFunctionalRequirements against FunctionalRequirements, there must be a way to answer questions like:
"What is worth more, being able to handle 100 concurrent users or being able to take credit card payments?"
If there isn't time or money to do both!
Who's the Customer?
[:Story: Stories] represent concrete requirements that make sense to the business, but Technical stories aren't the ones that leap to the forefront of a Customer's mind when they are envisaging what they want from their system.
To this end it is useful to have a TechnicalCustomer who will play the same role with respect to a technical story as a regular customer plays for other stories. However, there is one proviso, when planning, regular customers have the final say, because it is their money. If the TechnicalCustomer is unable to convince the regular Customer of the merit and worth of their Technical Stories, then the Technical Stories must lack sufficient merit!
Not all Technical Work is in Stories!
It is a mistake to capture all technical work as [:Story: stories]. This is particularly true of normal [http://www.refactoring.com/ refactoring] which should be an implicit, normal part of all development work.
Where it is necessary to discuss refactoring with customers, and schedule time for it to happen, there is a problem in the project, and/or the development process!