I have 6 departments, each with applications to maintain, and 4 developers. How do handle this in scrum?

You already know the root of the problem. Work your way from there...

1- Get the products owners (PO)/business...and let them know the situation.
2- With the POs, divide the departments into two backlog lists. Group them in a way so that the dept. that are most related to each other are bunched up. So now you have 2 backlogs.
3- POs will then re-prioritize based on what is best for the business as one entity and not on what is best for the department.
4- Divide the team. 2 devs and 2.5 devs, each will take care of one backlog.
5- If the two teams need to still know what the others do, apply scrum or scrums.

Just by doing that, you will improve the quality because devs will have a smaller scope to focus on.

Should technical work (non-code. Example: setting up servers, DBs, Hardware.. etc) be added as a user story to a backlog?

Short Answer; Yes

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 i.e. what is it that needs to be done.

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.

Where can I go to learn more about Scrum? mountaingoatsoftware.com

I get many questions regrading where to find a good source to learn "Scrum". One of my favourite is

http://www.mountaingoatsoftware.com/topics/scrum

Is the Sprint truly complete if QA still has work to do and how should it be solved using SCRUM?

Consider this as a solution. I will explain the reasoning behind after the solution. I do not know how big the team is, but I am working based on a 3 developers, 2 analysts scenario... the ratio can be changed....

>>Solution:
- Have Analysts. One position that cover both QA and business analysis roles.
- Keep user stories short.
- Release as often as possible to your testing environment. Every day, or every time a testable section is available.
- Consider regression testing every iteration. If automated, consider it more often than once every iteration. If manual, then at least once. (i.e. also consider this in iteration planning/Estimation)
- Extra: Consider unit testing. This will promote the team to focus on quality, rather than functionality.
- Define "done" as ready for live.

>>Reasoning:
Each iteration analysts are working on user stories for future iterations and test scripts for the current iteration. Also have another analysts taking on the role of testing the functional scripts of a user story not worked by him/herself. Once deployed to the testing environment, the analyst will test. The aim here is to avoid lingering untested features and undiscovered bugs from being in the system for too long. By doing the above, you will have the analysts busy with user stories and testing, thus eliminating the worry of people not having work to do.

By having user stories small enough, you will have proper functional testing, and since you are covering for regression testing, you are ensuring all testing from your end. within the iteration, you covered for the unit, functional, and regression testing.

If doing manual regression testing, then analysts, and developer cover the testing using the test scripts to ensure coverage.

Remember that in scrum, you use the "Skill set" and not the "role" or "position" of a person. so "theoretically" you can have developers only who are good at user stories/dev/testing... etc. So when dealing with an issue. think of the team doing something rather than the person with such and such role doing something.

What could be a list of potential definition of "Done" for user stories?

The word "Done" should not be used in any context except when one is saying the functionality is ready for live. The other word that should be used is either "finished" or "ready"

Mike Cohn has commented on user stories in a very well structured and coherent fashion in his books. A "ready" user story should the follow several attributes known as INVEST:

- Independent – No dependencies between stories.
- Negotiable – User Story is negotiable between the team and the customer.
- Valuable to the user – The functionality dictated by the user story should have value to end users.
- Estimate-able – The scrum team should be able to estimate the user story story
- Small – User Stories should be completed in a single sprint/iteration
- Testable – Test should cover everything that will allow the features to be "Done". This means that the user story should be able to be completed.