As part of the “scrum.org” webinar “Ask a Professional Scrum Trainer – Martin Hinshelwood – Answering Your Most Pressing Scrum Questions” they asked me several questions. Since not only was I on the spot and live, I thought I should answer each question that was asked again here, and those questions I did not get to.
In case you missed it, here is the recording of yesterday’s Ask a Professional Scrum Trainer webinar with Martin Hinshelwood! Watch here:
Estimation is a tricky topic, even if many folks invest in it. Though, my feeling is that the value of estimation is not in the resultant numbers, but in the discussion and illuminations that the activity brings to the Scrum Team.
Usually the team members from the agile product management or agile project management perspective they understand more by discussing it than become a wasted time. As the Scrum Team builds up its inherent knowledge of the product, the market and the technology they these activities should naturally streamline, and anything you can bring as they mature to minimize the waste in this process is a wonderful thing. Remember though, it’s not waste if it results in useful teachings.
When a Scrum Team is first starting out they have enough on their plate trying to deliver working software every Sprint to worry about the deep mechanics of Flow. Therefore, story points and velocity are a good starting place that provides a balance of the team learning how to communicate and decompose their work.
Story points are easy to understand, easy to implement, and great for not so mature teams that proved their mindset and skilled in agile product management or agile project management areas.
Once the team gets past the basics, they need to think about the optimization of their process. At the very least they should optimize at every Sprint Retrospective and quickly the question should come up: “Should we keep doing planning poker”. If the question comes up, then the answer is a resounding no!.
Once a Scrum Team can deliver working software (which is a standard for agile product management mindset or for agile project management mindset), at least at the end of every Sprint, then they should be ready to focus on optimizing their working flow.
That means dropping Velocity and story points in favor of four new metrics that will help them on the next leg of their journey of continuous improvement:
This metrics enables the Development Team to have a lot more interesting conversations about the work that is happening and the state of that work. Once Teams have a few Sprints worth of data, they realize that gaming the metrics they can just reduce the size of PBI.
The team spends more time looking at Sprint Refinement; the work gets smaller, and their flow gets better. In this fresh world of small PBI and greater predictability, the need to spend a lot of time on relative sizing disappears, and it becomes replaced by boolean sizing. Does a PBI fit or does it not?
My belief is that #NoEstimated is one way to do Boolean estimation. You can read about No estimates on Ron Jeffers post.
While there are no right answers, there are some answers that are better than others. For your given situation, select the most right answer and iteration to the best version of it.
Agile product management or Agile project management teams applied #no estimates first in Agile software development areas but now goes with the agile wave, everywhere.
You cannot afford in our digitalization world not to be agile and just doing agile.