If you have never had a sizing or estimation session before, it's the process by which any team member can hold a meeting to look at the tickets and give an estimation of how long it will take. This information is used to set the number of tickets to be worked on in a sprint, typically the next 2 or 3 weeks.
When starting to run estimation sessions a common question is what unit do we use to size. Is it a t-shirt size of small, medium or large? It maybe complexity points going up in a Fibonacci sequence and what's that again 1,2,3... oh no 1,1,2,4... hmmm... or maybe we use real time like hours and days. That way we can get rid of ambiguity right? But still it doesn't have to be an "accurate" estimation.
In my opinion these are distractions and all amount to the same answer, a number that we eventually use to try to predict how long our work takes. I do think there's a problem here and one important aspect is missed out which I do want to outline here and present a solution to tackle it.
The unit of size doesn't matter and neither does the estimation. The most important thing that is lost in most of these sessions is what the people are saying to you in the room. The numbers just give the members a chance to speak about them. Let's use a simple point sizing system as an example. 1, 2, 3, 5, 8 is the scale. If some one gave the ticket a 1 this means it's easy to do, no problem, could do it in 10 minutes before going for a tea break as we wait for the CI to build. If the ticket was given an 8 the message being given here is the person is very unclear of what is being stated to the point where there are very large unknowns.
They are saying they would need to find out more information probably from a knowledgable trusted source. What then should follow is a question of who can answer those questions if they are not already in the room.
If these conversations are being missed then I propose using this sizing system. Feel free to write these on cards and hand them out.
1 - Can do this with a blindfold and one hand tied behind my back.
2 - I've done some of this before and I know where to copy and paste the rest of it.
3 - There are some parts of this that I've never seen but heard the name from other conversations. I need time to look into it.
4 - Don't know anything about this, never heard of it and I don't even know who to ask about it.
Assign the number to whatever time metric you see fit but if these words were said out loud in the session there would be better estimations and far less ambiguity. Hopefully the person running the session would act upon these statements. In the case of 4 asking who has the information and getting the answers from them. In the case of 3 helping to break down what is unknown into further smaller tickets.
The one other metric from a well run session is the confidence of the team. If they were not confident going into the session then they should definitely be coming out of it.
In conclusion we use these agile sessions with a lot of ceremony and dis-regard the most important opportunity it offers us and that's team collaboration. It's a chance to make the team inclusive and gather consensus from members.
Top comments (0)