Long Answer;
A user story has 3 parts: As a [user/actor] I would like to [Action] so that [reason/value]
Whenever you make a decision, whether technical or not, you need to consider "why" we are doing what we are doing. Thus the last part of the user story has very high value to the owner. Example. why should we upgrade the server version from X to X+1. Another, Why should we increase the hard drive space from X GB to Y GB? It could be to support a new feature that will require lots of data storage or new DLLs from some server version, or lots of transactional audit data... etc. These points help put on paper in clear and concise way why we are doing a change
If you recall in scrum, during the iteration planning, we need to estimate how much effort is needed for a task. We estimate using points. Based on that you can estimate a task it takes to complete a technical or non-technical task. Remember, in scrum you estimate the effort to complete a task in full in accordance to your organization. Thus documentation, audit needs, any task required by your company would have to be considered during the iteration planning. So Hardware is a part of that. To estimate, you will need to look at the
Last, if you recall when working on a user story, the aim is to make it measurable. Thus you could end up with multiple stories to complete and epic story. Example: Epic. Build a server for Web application X. The stories title could be: Install OS, Install IIS or Apache, configure Ports, install DB server, Configure DB... etc. You see that you can take each of those and write a simple user story. In each case capturing a small piece of what needs to be done, and as mentioned above, capturing why we are doing it.
