Gespeichert von Jens Coldewey am Di, 07/07/2015 - 13:26

If you watch an arbitrary discussion about Scrum – at a user group, a conference, or any other opportunity – you could easily come to the conclusion that Sprint Planning is the major and most important ceremony in Scrum. People religiously discuss about the format of user stories, the “Definition of Ready”, and whether teams should compare their estimations with what it actually took them to finish a story. It becomes even worse when you look at Scrum tools: They usually offer at least three different approaches to estimation and tracking you can choose from and most users choose all three at once. Observing organizations that take this approach you often come to the impression that they use most of their time for planning, while the rest of their time is wasted complaining about “all this Scrum overhead”.

But Scrum is not about planning! It is neither about Story Points nor Sprint Commitment nor Backlog Grooming. Scrum is about Delivery in first place. And about Learning in second.

What many planning and reporting enthusiasts ignore is the fundamental change that comes with fast sprints. If you deliver every second week (or even more often), you don’t need to invest days into breaking down stories into tasks, estimating them and comparing them to earlier estimates. You don’t need to “track progress” by tasks accomplished. Either a story is done or it isn’t. “The primary measure of progress is working software” is one of the agile practices from the Agile Manifesto and Scrum is no different.

If a team focuses on delivering valuable software at a constant pace, five or ten stories a week, you can simply get rid of all the overhead ceremonies of waterfall as much as you don’t need to provide food, drinking, sleep or combing off to your car, although that was a great idea when you were still using horses to get to the next town.

So why does Scrum feature a Sprint Planning Session anyhow? One important aspect of delivering software is the alignment on what to deliver. Estimating a new feature is an excellent way to think through it in detail. And estimating as a team using planning poker makes sure that you have the diverse competencies of your team aligning on what to build. Planning in Scrum helps you to go through this process in a disciplined way. This simplifies delivery and reduces bad surprises, which is of tremendous value. Nothing more.

And what about all these important client commitments and deadlines you have to take care off? Of course these are important preparations to earn money with the software you delivered. But this has only very little connection to Sprint planning. If you want to predict what the team does, use statistical analysis of what the team actually did deliver – which is way more accurate than analysis of what they thought they’d deliver. You can use all kinds of analysis tools here, probability funnels and empirical planning being only the most prominent ones. As long as the priorities are set right, you will generate way more value than you did without Scrum.

If you do these types of analysis, you may find that the estimation accuracy is among the least important influence factors to the stability of your plans. Most of the times stability is about setting a context in which the team can deliver in a stable frequency. And this does not need more accurate predictions, but a thorough understanding and adoption of agile development practices and an environment that is focused on supporting the teams and not micro-managing them. If you trust your team, let them do their work. If you don’t trust the team you have a completely different problem that no planning approach can solve.

So when you do Scrum, relax about planning. As long as you set the right priorities and the team delivers at a consistent pace, things are fine. And if you have problems with any of these, it is the Retrospectives where this needs to be solved. Just ask your team “What do you need to deliver?” – and for heaven’s sake listen to their answers! If you save two hours per sprint by getting rid of over-accurate planning, these Retrospectives even come for free.