AS A [person/role]
I NEED TO [do something] 
SO THAT [provides business value]. 

For your example a user story might look like this:

AS A user of the XYZ application
I NEED TO get reports of ABC faster
SO THAT we can increase our conversion rates.
ACCEPTANCE CRITERIA - The database reliably completes transactions on average in 2 seconds.

I ve added an acceptance criteria because without this you will never know when the job is done. Now at this point, you have a business case for upgrading the database. This story would be decomposed into a story where the role is the IT department or DBA, like so:

AS AN administrator for the database server
I NEED TO upgrade to the latest version of FancyDB 11.7
SO THAT we can improve the average transaction time for XYZ users to 2 seconds.
ACCEPTANCE CRITERIA - the new version starts successfully, the XYZ developers sign off on the test installation of 11.7, data migration is successful, we have cut over to the new db

When story decomposition is added to your box of tools, the story must start from where the user is a real part of the business, and the "so that" leads to a real business value. Then decompose the story into one or more stories in which internal users do things "so that" real users get the benefits in need.

Here are a couple of articles that talk about Story Decomposition:

http://jpattonassociates.com/the_shrinking_story/

http://old.cognitive-edge.com/wp-content/uploads/1999/11/56-1999-11-Paradox-of-Story.pdf

Scrum is not very prescriptive and there is nothing in Scrum that forces you to use User Stories for your Product Backlog Items (PBIs). You can definitely do Scrum without capturing requirements/features as user stories, user stories are just one way to do it. Actually, stories do work for many teams, especially web development teams, but this doesn t mean that they work in all cases and on every project (many projects are web development but not all, like in your case). There is no consensus about using stories.

That said, the recommended template for User Stories is actually As a <role>, I want to <action> so that <benefits>. I don t mean to be picky but, if you choose to use stories, I d warmly suggest to use it as is, without removing any part. First, using a role do help (a same user/person can have several roles) to discover stories. Then specifying the benefits is really important to expose the business value of a story in order to prioritize them well. Regarding the value, you should think of it as end-user/customer ("put on customer glasses" --Mary Poppendieck). It is really not always that easy to express the benefits, but some tools might help and my preferred one is the 5 whys (which is used for root cause analysis).

In your case, this could lead to something like: As the IT department, I want the database to be upgraded so that users can benefits from the latest features of the application and [do a better job|have a better user experience] (not very satisfying though, use the 5 whys).

But personally I don t find that user stories are the best medium for technical tasks even if it is clearly possible to use them and if they have their strengths. Theoretically, stories capture the essence, not the details and should be a support for the discussion. I may be wrong but I don t find that technical tasks offer much room for discussion and creativity. So, depending on who will read them, what the should convey, I might use them or not. Another option could be to mix stories with another formalism for your PBIs. As I said, the point is not to use stories, the point is to have a list of prioritized and estimated items.

Upgrade the database may be one of the tasks involved in implementing another story that brings direct value to the user, for example I as a user can add a new foo to my bar.

If adding a foo to a bar requires a database upgrade behind the scenes, then you would include that work in implementing that user story.

User stories are worded this way to help ensure that any work directly benefits the end user in some way.

This gets to the forefront of why user stories are so great.

What benefit does upgrading your database give to the end user? None? Then don t spend the time and money doing it. Spend that time and money providing something that will give value to your end user.

If it does? Then think about it the other way. Maybe you can only implement a new feature when you have version x of your database software? In the dependency of the story, you could mention that database upgrade required to provide this feature.

tl;dr Don t just upgrade for the sake of it. Make sure upgrading adds tangible value to your customers.

Generally, technical tasks in the PB are frowned upon because they very rarely directly deliver business value to the customer. That s why User Stories are popular, because they force you to think about the business value of the story, and who it s being delivered to.

So, why are you upgrading the database? Can you identify business value in upgrading it, and why should the Product Owner agree to let you upgrade the database instead of building new features?

Is it because of a new feature that will make it possible or make it easier to do something in your application? In that case, that something should be the PB item, and the database upgrade should be a task within that story. If you already have stories on the PB that would benefit from the upgrade, then you should increase the estimates for one or more of those stories, and add the upgrade as a technical task to the story.

Is it because the vendor of the database is cutting off an old version from support? In that case you could have the upgrade as the story; something like, "As the department manager, I want to be sure that we have support for all of the software so that the continuity of the business isn t at risk if something goes wrong". Even that s pushing it, though. Generally, this kind of reason isn t really part of a project, unless the project has been going on so long the system software goes off support.

Is it for performance? Then the story should be about some aspect of the performance of the application that needs to be improved to deliver business value. Something like, "As a CSR I need to be able to retrieve customer information in a reasonable time so that customers on the phone are satisfied with our service". Then the upgrade becomes a task under that story.

Is it for some totally technical reason? If you can t identify how the upgrade is going to deliver business value, then why would you do it? Why would the Product Owner select it for a Sprint?

It s simply "Upgrade the Database" or maybe "When the new version is installed, there must be a way to migrate the existing database". If you already know more details about this step, then include them. But the story mostly exists to make sure something isn t forgotten; it s not to be detailed.

Later, when you get to implement this story, you can flesh it out (which tables, do we need one or more backups, is there a fall back scenario, etc).

OTOH, if the project is more complex, this can become a "tag", like a post-it notice which must be attached to many stories. That means you must include this as a "sub story" to all stories which change the database. As you can see, these "project-spanning stories" are a bit hard to track with agile methods.

Infrastructure stories do not need to follow the prescribed story template. Just write down what needs to be done and estimate accordingly

How about:

As the application support person I want to be on the latest version of database because it is more reliable / more secure / whatever.

You could even phrase refactoring like that:

As the application developer I want all the data classes in one module so that I can add new fields to the app very quickly.

1. Who benefits
2. What you want to do
3. What the benefit is

Ideally you don t want all the stories to have 1 be developers, but a few make sense (sharpening your ax instead of cutting down trees and all that).