Recently, a Scrum Mater asked me a question about estimation in Scrum.
SM: Kemmy, my team is estimating but we need to start doing this consistently and also, understand the best way to estimate properly. Can you help with this?
Me: How about we jump on a call to talk about this.
I needed to be sure about the purpose of estimating the User stories and why the SM thinks the team needs to get it right. Estimation as a topic in Scrum is very controversial depending on whom you are speaking to. There is the #NoEstimates movement that was created and designed to eliminate the waste of ‘conversations about the software’ instead of building the software. You can read more about the #No Estimation Movement here.
Some context, the team in question is made of Content Managers, Copywriters, designers and QAs. They appear to follow the project lifecycle process and in a mini “agile-waterfall”(i.e Analysis- Design- Development- Testing).
SM: Thanks for connecting with me.
Me: No worries, how can I help?
SM: I am thinking my team needs to start estimating the user stories and not sure how to go about it. My team works mainly on creating content and translating it to french then testing the deliverables.
Me: What are you aiming to solve by estimating these stories? Are some people outside of your team requesting this estimation? Does the team need it for planning?
SM: None of this. It is just that we are doing scrum and also, other teams are already estimating stories.
Me: Have you tried tracking your team’s Cycle time instead? Or perhaps Lead Time? Given the nature of what your team does, it might be more useful to track continuous improvement rather than estimating stories.