I am always an admirer of your blogs and posts. The story telling is next level.
While I was reading and got immersed into it, I literally had face palm moment and a bit of laughter at "God forbid. What if you have to take a vacation?". Haha. Because this is exactly what happens in real. I have been there , done that.
Question: Do you have any blog or articl about starting writing/story telling journey? I would love to read.
"100% extended utilization is just pointing to a CPU crash", so true, as a human, if we want to make the work fun and focused, we can not push ourselves beyond 80%. Human brain tends to slow down and burn out leading to many other cascading problems.
Question: How do we justify and convince the 2:1 ratio? because it makes them feel overallocated QA, while we know it is not?
"What if 2 people decide to move on from the company at the same time?" - You hit the nail hard ;)
What we do in current job is to allocate a optimistic availability of every team member during planning and record them as hours and plan the tasks based on that while keeping extra buffer for emergencies and unexpected situations.
We follow exactly the 2nd approach at our work ( Clipboard Health) and when we started implementing the process, it took sometime to adapt it for the whole team but it then turned out to scale well. I totally agree on point where QA might miss the whole context or nitty gritty of features as they are not deeply involved in testing. To add , we generally have a bug bash for every critical features before release, where we would invite cross teams to participate too.
Glad you liked it and find value in my reading my thoughts. I don't have a specific resource to learn storytelling. It's mostly come as a result of reading and writing blogs over time.
2:1 ratio is a tall ask, the person you need to convince is the org leader and you should have data points on why? Conveying the value of testing is hard. It's easier to convince in env where a bug slip to prod can have monetory impact.
Yes, bug bashes and pair testing are great way to get the team involved and spread the knowledge.
I am always an admirer of your blogs and posts. The story telling is next level.
While I was reading and got immersed into it, I literally had face palm moment and a bit of laughter at "God forbid. What if you have to take a vacation?". Haha. Because this is exactly what happens in real. I have been there , done that.
Question: Do you have any blog or articl about starting writing/story telling journey? I would love to read.
"100% extended utilization is just pointing to a CPU crash", so true, as a human, if we want to make the work fun and focused, we can not push ourselves beyond 80%. Human brain tends to slow down and burn out leading to many other cascading problems.
Question: How do we justify and convince the 2:1 ratio? because it makes them feel overallocated QA, while we know it is not?
"What if 2 people decide to move on from the company at the same time?" - You hit the nail hard ;)
What we do in current job is to allocate a optimistic availability of every team member during planning and record them as hours and plan the tasks based on that while keeping extra buffer for emergencies and unexpected situations.
We follow exactly the 2nd approach at our work ( Clipboard Health) and when we started implementing the process, it took sometime to adapt it for the whole team but it then turned out to scale well. I totally agree on point where QA might miss the whole context or nitty gritty of features as they are not deeply involved in testing. To add , we generally have a bug bash for every critical features before release, where we would invite cross teams to participate too.
Thanks for your detailed article.
Glad you liked it and find value in my reading my thoughts. I don't have a specific resource to learn storytelling. It's mostly come as a result of reading and writing blogs over time.
2:1 ratio is a tall ask, the person you need to convince is the org leader and you should have data points on why? Conveying the value of testing is hard. It's easier to convince in env where a bug slip to prod can have monetory impact.
Yes, bug bashes and pair testing are great way to get the team involved and spread the knowledge.