We faced lately in our team an issue of wasting time, in a lot of the meetings (scrum ceremonies) most people are silent and a few of us talks, not because they are shy or the few of us likes to talk, the problem is that not everyone is needed to that meeting actually
Our team consists of 4 Frontend developers and 3 Backend developers and 1 DevOps guy and a Product owner (also acting as the Scrum master), and whenever we have a new story we try to break it down so we can have separate stories per discipline, usually it is either FE or BE or DevOps work.
What we used to do is to have as any scrum team refinement sessions to talk and explain the stories that are created by the product owner, if the majority are FE stories then the BE developers keep silent with very little interaction, and the same for the FE in case it is BE ticket.
We value everyone’s input in the team even if he/she is talking about something that they are not going to implement by themselves, that’s why it is important to make the whole team aware of what is in the pipeline for the team to implement, and sometimes the discussion goes too deep in technical issues, which is a little bit boring for the non-technical guy and for developers from the other side.
After some thinking and based on a previous experience I had in a different company, I suggested the following strategy to mitigate the effect of wasting the time of the unnecessary person in each refinement meeting:
Step1: Business Brief Session
Some people call it a grooming meeting, and it fits the idea but actually, others see that not convenient because of the far meaning of grooming 🤷♂️
In this meeting, we (the whole team) come together and only discuss the business part with the product owner, he gives us a brief about the feature and what is the expected impact and we as a technical team try to understand all the business expectations out of this implementation and what would the end-user see and feel about it.
In this phase, we never talk technically only get that brief and write the main points into the ticket description.
Step2: Technical Refinement
This meeting is managed and organized by each team separately, the FE team picks the FE tickets and the BE team picks their tickets as well, and create separate meetings on their own.
Talk as deep as possible and share ideas of implementation, also this requires us to add technical comments about the proposed solution into the ticket itself, which makes the time of implementation smaller eventually.
Also, that will save the time of people who are not interested or their technical input in that part is not very important or to even aware of this discipline.
Step3: Collective Refinement
This is the final refinement session, the whole team attends it again, we have all the tickets filled with the needed information (business, technical), and the whole team has a great understanding of what needs to be implemented and highlights at least of how it will be implemented (in step2).
The practice here is to get ticket by ticket and read it out loud (this could be by the PM or by any member of the team) so everyone could get a good idea about that ticket and the amount of effort needed to be implemented as well.
The final step is to Vote for the story points, the whole team should share in that so we can manage the expectations by the end of the sprint, as currently, we are working from home so we use scrum poker 🔗 to vote for story points and it is great.
Now based on our definition of ready, our tickets should be ready to be picked up in the next sprint planning.
Conclusion
There is no one way of managing a scrum team, but the way I explained in this article fits us best and it is as follow
Don’t include people into a meeting they are not needed to, and for refinements please make it through the 3 steps: Business Brief, Technical, and Collective and you will be surprised by how effective it is
If you have a different experience I’ll be happy to get it on Twitter 🔗
Resources
- Image by Annie Spratt on Unsplash 🔗