As part of the Scrum.org webinar “Ask a Professional Scrum Trainer - Martin Hinshelwood - Answering Your Most Pressing Scrum Questions” I was asked a number of questions. Since not only was I on the spot and live, I thought that I should answer each question that was asked again here, as well as 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: http://ow.ly/ijiM50vwEkD
Estimation is a tricky topic as many folks are heavily invested in it. 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. They understand more by discussing it than is wasted in the time it takes. 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 minimise the waste in this process is a good thing. Remember though, it’s not waste if it results in useful learnings.
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. So 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 immature teams. Once the team gets past the basics they need to start thinking about optimisation of their process. At the very least they should be optimising at every Sprint Retrospective and very 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 is able to deliver working software at least at the end of every Sprint then they should be ready to start focusing on optimising their Flow. That means dropping Velocity and Story Points in favour of four new metrics that will help them on the next leg of their journey of continuous improvement:
These metrics enable the Development Team to start having 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 start to realise that to game the metrics they can just reduce the size of PBI. They spend more time looking at Sprint Refinement, the work gets smaller, and their flow gets better. In this new world of small PBI and a greater degree of predictability the need to spend a lot of time on relative sizing disappears and is naturally replaced by boolean sizing. Does a PBI fit or does it not.
My feeling is that #NoEstimated is one way to do boolean estimation. You can read about NoEstimates on Ron Jeffers post.
Read the Kanban Guide for Scrum Teams and Actionable Agile Metrics for Predictability from Daniel Vacanti .
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.
If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.
We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.
