Nicely explained.
As a team we need to understand that in a sprint we deliver a set of stories as a team which is Devs + QAs.
Also, I don't recall if any team gives away Man/Woman of the Sprint award for an exceptional individual performance in a sprint.
Great read. You dropped some truth bombs here 😅. I'll try to take lesson from this and work better.
Great read. It definitely helps if team members can help each other out by reviewing PRs. It takes a lot of load from the EM. Do you currently practise this in your company? Would you say it was a success?
It sounds like an interesting approach, however, I have to disagree on your point for tracking with Jira. In the world of Agile, these metrics are intended purely to predict time needed to develop future tasks/stories, mainly because companies like predictable, they feel better knowing that once they have these metrics promises to clients can be made and kept(at least most of the time).
I am curious, how would you handle the workload problem, where QAs are waiting for Devs to finish a certain functionality in order to get "unblocked". This is always a tricky balance to keep in my view. And if devs are focusing on helping others, surely, there will be delays in the development process. Another thing to mention is that a lot of people feel uncomfortable asking for help, and motivating people to communicate more and ask for assistance is another challenge on its own, it will be interesting to hear/read your opinion on this topic as well.
And last.. is this an official framework like Scrum or is it something internal that you came up with in your company? What steps did you take to reach to this "framework" and what challenges did you face when going through this process change?
Thanks for the article!
Rizel Scarlett
Staff Developer Advocate @ TBD
I really love this. My former manager at Botany was one of the first people to introduce this concept to me of taking a little break between tickets to learn and do code reviews. This blog post was a great reminder.