Coaching by doing

Recently, I was not happy with the bug reports on one of my team. The title was generic, there was little or too much information in its description, logs, response was not formatted and the attachments at times made very little sense.

My initial thought was to forward 'how to write good bug reports' blog links from the web but something in me did not wanted me to do it. They explored well and the bugs they found were very good. Also, I did not feel a meeting or a workshop targeting only bug writing skills would have the right impact on this team.

So instead of direct coaching or sharing blog links I started to reproduce the bugs locally and started editing the bug title/description/code format/attachments, etc in the bug reports. I did not mention anything to the team.

After couple of weeks I started noticing a change. The bug reports got better!
The title was appropriate, description much improved, code well formatted with screen shots and there was also gifs in attachment.

When I thanked the team for observing and improving the bug descriptions they mentioned how much my changes to the bug description helped them understand the - why I am doing it and the value in it. They wanted to get better too but did not know how. The changes served them as examples on how to approach it. This was extremely satisfying to me too because I was able to influence my team by just doing it.

TOO BIG - the mindmap

I have always believed that testers should actively play a part on the left side of the scrum board in preventing defects and not just the right side of it where we find them.

Gojko Adzic, one of my favourite agilist introduces 'TOO BIG' heuristic that can help us with that in his latest post. You can read the full post here https://gojko.net/2017/01/05/user-stories-too-big.html 

I have created a mindmap [.PDF | .MUP | .MM] of it for my reference. Hope you find it useful too.