TL;DR: Never assume that individuals or your team know anything when starting out, even the basics. Even if they seem to know the basics, cover it off anyway so everyone has the same baseline to start with. State the obvious, make it explicit and don’t shy away from it. Then build on top of that foundation, adding the necessary layers of complexity required in your organisation.
It’s been a while since I’ve written an article so this certainly feels quite alien to me. However, I thought this is a good topic to write about as (1) it’s something I recently experienced myself and (2) I feel that a lot of people, Delivery Managers or Scrum Masters in particular, can get some value out of this.
Let me tell you of a recent experience I had. Another engineering team were going to have a Backlog Grooming & Estimation session. They are working in fortnightly sprints, following the usual Agile ceremonies. They have previously been doing their grooming in small squads of the people who are essential to that ticket, and they would estimate it themselves before coming to the planning session.
The first issue here is that estimations seemed to wildly differ to reality, often underestimated. Secondly, estimations were only based on a few people’s understanding of a ticket within a small squad, rather than the whole team. This led the Delivery Lead to wanting to try out Planning Poker with the team. I decided to pop along to this to observe the transition and see how the team’s first session goes, ultimately helping facilitate the session.
So what happened?
We started the session asking if everyone had done Planning Poker before. Now, this was a team of experienced engineers and to my surprise, there were a few engineers who had never done it but understood the concept. What they didn’t really understand was why, and the value behind the exercise.
So I spent a little time recapping the concept, the practical of how the session runs, and the value in the conversations had by the team.
Next, when playing your estimation, surely you’re thinking of yourselves as a cross functional team and therefore looking at the ticket in the same way? Wrong. Many engineers to start with only thought about things from their perspective, e.g. a Software Engineer may say, “I only need to write 2 lines of code for this to work” while an Infrastructure Engineer may say, “but I need to hook up 200 things together for this to work.” This was a huge eye opener for the team and really got them thinking of each piece of work as a whole cross functional item, rather than a single task for them as an individual.
Next, surely everyone understands the requirements when they have been read out? Wrong. The first couple of tickets showed estimations ranging from 0 to 13 (we capped the highest estimation at 13, else it’ll be infinity). The reason? Purely down to a fundamental misunderstanding of what the ticket is asking despite being read out. A quick conversation here revealed the unknown information and on the next round, we saw a convergence in their estimations.
Now why am I saying all of this? It’s quite simple – this is an experienced engineering team who have been running sprints for a little while. Each engineer on this team is experienced having worked in different teams in the past with their own flavours of Agile. They have all performed some form of estimations, but even then we had to press the reset button and start from scratch so the whole team had a baseline understanding. This was key to ensuring the team actually got value out of the session.
So in summary, this is something to really think about whenever working with your team. Don’t assume that the team may already know stuff, even if it’s internal domain knowledge or an industry accepted practice. It’s always best to start from scratch and recap the basics – no matter how basic it is! You can then build on top of this and add the various other layers of complexity you need to, eventually shaping the team to working in the most efficient way possible.