Have you ever had to do this?
Start work on User Story 1 which has 5 tasks, you agree to work on all of them in a single iteration. Then half-way through the iteration a new priority comes up in User Story 2. You are "in the spirit of delivering most value to the company" and agree to context-switch to User Story 2.
Then you find out that User Story 2 has functional requirements, technical debt, and environmental dependencies that make it at least a 3 week project just to get it off the ground, much less progress it to the expectation.
You mention the impediments, (daily) at the stand up and find that only you are responsible to drive the impediments to the end. Each day, the Scrum Master continually asks "Where are we on User Story 2" your response never changes day to day, week to week, until finally.... one day, sometime later... The stars align the impediment breaks and everyone is happy? (forget about all the reasons it took so long, or other department's responsibilities)
Indeed it should be a happy time because now, after three weeks; User Story 2 can get underway. The only problem is that User Story 2 is now three weeks (later) and User Story 1 is still incomplete.
This is the danger of context switching and it is a major minefield of potential disasters. Sometimes they work out, but my experience is that the odds are against you.
Next time you encounter a context switch, treat it like a greenfield project.
Don't assume that anything will just work. e.g. The project will compile, the dev-ops work is in place, the check-in process is good, inter-machine dependencies are satisfied, and most importantly; there is no technical debt.
How to Protect Your Reputation
Be disciplined on that User Story! Create a task for any work that takes more than 1 hour. Log everything: Each task becomes a log of the unknown journey ahead. Set the right priorities and most importantly ensure the dependencies are clearly marked and are actively being worked on. These tasks are the only real way to do an introspective on the whats, whys, whens and hows. If your scrum master has any proper authority all issues will become a backlogged item of things to improve going forward.
In the heat of huge delivery expectations, almost nobody cares about the reasons for impediments. The reason is those expectations, are created by contracts to get something done; which, has failed to take into consideration the environment which you (the person in the trenches) must work in.
It's similar to what we've read about World War I, "the trench war". The war to end all wars, was a missed expectation. It didn't end all wars, and the "trench" life was miserable (if one survived).
(open source and trusted by devs everywhere ❤️)