This is one of the major problems with "big-A-Agile" development: it's primarily focused on development. If system documentation matters to your users (and it usually does), your technical writers and their work-product need to be part of the sprint. In the "small-a-agile" community, we've come to understand that there is more to product than just code. We've integrate testers and testing into sprints, including making sure the testers know enough about what is being coded that they can test inside the sprint. We need to do the same with the technical writers, although I don't know anyone who's doing it yet.
The crimes that are committed in the name of Agile these days make me sad. Lots of people are having a hard time making this transition.
Agile Manifesto: "We value people and interactions over process and tools.". When the people are clearly hurting, the process is wrong. I don't want to tell you how to do it, but will share how I do it.
In my teams, the important part is to avoid committing to a shared repo code that is broken in ways that will waste the rest of the team's time. In this sense only, I strive to 'deliver working code every day'. Don't break QA. Don't block other developers. Ideally I never check in any bugs. (ha ha).
The implication is not that you have to commit something every day. The implication is that you should only commit good stuff, so that each day you can get a build of all the good stuff that anyone committed. This way the team keeps firing on all cylinders.
In my teams QA is constant. I build commercial products, so the project is never over until the product is obsolete. QA Engineers test the features that are available to test. QA Engineers always have a backlog. There is never enough QA time to test or automate everything we would idealistically want.
If developers need multiple days before merging in changes for a feature or fix, it's fine, encouraged if it helps them get the code right before risking our time. Developers can commit code to their private repo or branch without affecting the team or QA. Developers can run unit tests or regression automation on code built from a developer's repo or private branch. On particularly risky cases a QA Engineer will work with the developer to test before merging, to protect the team from delay.
In this sense, I practice what your managers want. Almost every day for the last 12 years my development teams have had code that works in the shared repository. We're always almost ready to ship. Occasionally we do not achieve this but we don't worry too much about it. Sometimes it is intentional, to accomodate major tools changes or difficult merges.
The Agile Manifesto, to me, sums up the best of the new thinking on development process that emerged in the 1990's. I'm pretty much a true believer in those principles, but the process details can vary. As I see it, the point of Agile is to adapt your process to your product's and clients' needs, not to be a slave to process.
Best Answer
The most common means of tracking a sprint is to use a Burn-down Chart. Basically you total up all your estimated tasks that you've committed to for the sprint. As you complete each task, you subtract the estimated points and plot the new point. The goal is to have zero points left at the end of the sprint.