My problem with ‘grooming’
This morning I was documenting one of the problems I observed within an engineering team and suprisingly even to me: ‘grooming’ calls is one of them. Like they say; the ‘road to hell is paved by good intentions’
The purpose of grooming calls at least in my experience is to breakdown features the team would be working on into sizeable bits that the team can work on — sound great right?
The problem however is pulling people into a call during the day to come ‘breakdown’ features that they are interacting with for the first time; is a recipe for good disaster. Even worse; these grooming calls are usually handled by team leads who sometimes are not directly working on these features and engineers are expected to give an estimate on the get-go.
Even if there will be a ‘grooming’ call, engineers should be given access to designs and APIs ahead of such call so that they call take a look at the feature, have a good understanding — the understanding might not be 100% but they can check API behaviors to see if there are properties that need to be added from the response, if there are endpoints that exists, etc. If you think about it, this is actually ‘grooming’ because you are gathering as much context as possible around what you are building, you can then go into sprint planning with this information you have at hand.
