Mastering Estimations in Scrum

Today, I attended a session on Mastering Estimations in Scrum by AgilePK. The session was focused around three things

1. What is estimation, Why it is important?
2. How to estimate systematically
3. What are common mistakes people do

I had to leave after two talks but both talks were insightful with clear directions, engaging and relevant.

One key takeaway was the importance of incorporating a 20% buffer with low priority tasks in addition to story point estimations. The speakers emphasized the need to assess whether external demands align with the sprint goal. If urgent work can be accommodated within the buffer without compromising the sprint goal, it is acceptable. However, if it poses a risk, it is recommended to have a discussion and consider ending the current sprint to start a new one.

Our speaker, Misam Abbas, engaged volunteers from different roles (developers, scrum master, solution architect) in a scenario where the product owner demanded a story to be completed within two days. This exercise revealed that despite the knowledge gained during the session, people tend to fall back into common estimation mistakes. Rather than engaging in negotiation and discussing success criteria, requirements, story points, and capacity, the focus shifted to how quickly the task could be completed, even if it meant delivering an incomplete solution with subsequent patches.

I really appreciate and acknowledge the efforts by AgilePK. I will be looking forward for more engagements.

From my experiences, we face similar issues during planning meetings with stakeholders. The stakeholders often inquire about the time required for a solution. Instead of speaking about how much value we can deliver in continuous iterations, the emphasize is on "The Demo/Launch Date". Any forecast presented is perceived as a lengthy timeframe.

It is disheartening to observe that despite the widespread desire for agile methodologies, continuous delivery, and the values associated with agility, many individuals and teams resist change in practice. These long-standing practices and mindsets seem deeply ingrained and show reluctance to adapt.