A bit more light-hearted than the title might sound but how often does your day actually go the way you intend it to?
Let’s say that in the daily standup, you tell your team that you plan to write some new automation tests but you run into a bunch of configuration issues once you get started. These issues end up taking you the whole day to solve and then you don’t end up doing what you actually planned from the morning.
This may or may not be what I’m experiencing today…
Keen to hear how often this happens to other people though!
Great topic! So, as the only tester in my org, my day can look really different from one day to the next. What works for me is basing everything on Priority. I try to prioritize my work really carefully because something could get lost between the various topics.
I have a QA channel where I post my status for the day. And, today’s post is…well, discovering what I should prioritize because I don’t always know what is top priority.
For me, I have to clearly communicate what I’m working on and also ask what I should be working on.
And, if a higher priority item comes through, then I switch to that and communicate that change to any relevant parties.
I don’t think I think about whether my day goes according to plan. The focus is more about “Am I doing what is relevant and needed” vs. “This is what I planned to do”.
Hope this helps, and I’m happy to elaborate on anything I’ve said here.
I will say, if it’s a quiet day and I finish what I said I would do, that’s pretty sweet, but probably not the norm.
I always start my day with a plan—typically aligned with sprint priorities or the tasks I’ve committed to in stand-up. But in reality, it’s quite common for things not to go exactly as planned.
There have been times when I planned to write new tests or work on an assigned task, but as soon as I got started, I ran into configuration issues maybe -with the test environment, tool setup, unplanned meetings, or other dependencies. What I initially expected to be a quick task ended up taking the entire day just to troubleshoot and resolve setup problems.
When that happens, I usually raise a sub-task or blocker ticket and mark the original task as blocked in our tracking system (like Jira). I try to resolve the issue myself first, but if it takes too long or is outside my scope, I reach out to the team for help or raise it in the next stand-up.
The key for me is communication—I make sure the team knows what’s happening so there are no surprises. If I’m working solo, I manage and reprioritize tasks myself and document what shifted. If I’m part of a team, I escalate or reassign tasks where appropriate.
While I start each day with clear goals, I stay flexible. Not finishing what I originally planned isn’t necessarily a problem—as long as I’m unblocking issues, solving real problems, and keeping the team informed, I’m still delivering value.
More often than I’d like to admit. I’d normally proceed with a nice checklist, and somehow a few hours before lunch something had gone wrong already: “blockers being set upon me mysteriously,” imminent headaches from configuration problems, or just that little Ping from someone with a quick question.
So, in my opinion, standups are somewhat more like guidelines than promises. I generally view it as a “bonus day” when, by some extraordinary circumstance, I manage to stick to my very original plan without detours!
Will be curious to hear if anyone here has actually worked out the formula to keep a day on track!
We have that. Our moto is “plan for the week adapt for the day”. So we set our own targets of what we want to achieve for the week and on slack we post what we will be doing that day. So if we feel our targets are at risk because we’ve been sent off course, then as part of that we can ask for help.
When our plans get kicked off course, the most common courses are either an incident or an opportunity that the business ups the priority on. Other than that it has to be like you said, those tasks we thought would be simple and we’ve uncovered a thread of impacts that you think “oh…we didn’t estimate that very well” which you hope the lessons learned will come out in the retro.
Not very often as I get notified about priority tasks midday which means my plan then changes to incorporate them.
My weeks are better planned in that sense because I maintain a list of tasks I need to do and when I hit some kind of tester’s block I switch to another task to clear up my mind.
Also, notifying the team about what you’re testing also helps but I think what helps more is a team discussion of who will deliver what and when. That way the dev teams get to know when a dependency would be resolved and the QA knows exactly how to plan and coordinate the testing.
For example: You might be working on a feature where the backend gets tested first but a few of it’s tests are better done with a mobile build.
But to answer your question, never there is always someone who needs help or this or that, even if I block my agenda. I have to learn to say ‘No’ much more often
Happens way more often than I’d like to admit I start with a neat plan, then one “quick fix” derails the whole day. Honestly I think surprise detours are just part of the job.
I think one of the key themes here is communication.
If you’re making your team aware of how your day is going, changes in plans might not always feel like a negative thing.
There’s times where I’ve felt stuck and the original plan I had might not be going well but when I’ve notified people of the issue, we can usually fix it together and get the plan back on track.
One of the challenges, I think, is getting everyone on the same wavelength of communication.
Devs can sometimes make changes that affect the whole system but they might not always make the rest of the team aware. This is one of the things that’s been derailing my plans lately.
Something I’d definitely like to raise in my next retro.
At least you have retrospectives. Which reminds me, I need to make a list of process change proposals and ways to gently bring them forwards.
Almost never, if you are new in a job, you will be forever underestimating based on past jobs. If you are in any way neurodivergent you will be promising the moon-on-a-stick to the team and to yourself. In fact you probably will find that everyone else in your team does the same thing. Another good reason to cut through the waffle of status updates and decide what can be done to unblock yourself and then ask for help daily.
there is always someone who needs help or this or that, even if I block my agenda. I have to learn to say ‘No’ much more often
Just realized that if I plan my day not to go as planned, then my day goes as planned 