Sprint Planning in Scrum (Part 1): Why sprints will never be perfect

Scrum vs. Perfectionism

Sprint planning and perfectionism only fit together to a limited extent. Perfectionism conflicts with the basic idea of Scrum. Scrum is primarily characterized by it iterative and regular approach. The process is mainly based on experience and is divided into regularly repeating stages called “Sprints”. Let’s take a look at why your team won’t think of everything in sprint planning and why that’s totally okay.

Why Sprints Will Never be Perfect

It’s rather rare for Scrum teams to look back at the end of a sprint and really everything happened as planned. Often the Scrum Master pleads for better planning of the next iteration. With regard to the Sprint Retrospective this makes totally sense when it comes to finding improvement potential and not making the same mistakes again. Nevertheless, every part of a sprint isn’t predictable - even if a sprint only lasts 30 days, for example. In addition, it is difficult to identify every required task perfectly. New tasks may arise during the sprint as a prerequisite for another important task of that iteration. Contrary, some tasks may not be necessary at all or may have to be postponed.

Let’s take a simple example: a new product description for an online shop. After the online editor has written the first draft, he will forward it to the product management for review. Since the editor has been with the company for a very long time and has a great deal of know-how about the product range, this step is normally only a formality. Which means the time required for the task has been estimated very low. Now, however, an important detail of the product has changed in the development phase, about which the editor hasn’t been informed. This now results in several revision loops between the editorial team and product management. The task therefore takes much longer than originally expected. On the other hand, it is possible that the editor plans more time for a different product description because he knows the responding product is very complicated. But in this case the product management is completely satisfied with his first draft and no further revisions are necessary. This process was much faster than expected. You may already notice what we’re aiming at: you will never predict everything perfectly. And the same goes for the Scrum Team. No matter how hard they try to plan a sprint perfectly and to see all tasks and possible impairments, it is simply not possible to plan each iteration perfectly.

How to Solve this Problem

So how can you deal with sprint planning meetings in the future? Instead of identifying every single task and estimating the effort, you should focus on the most important tasks. Based on those, you can then decide how many product backlog items should be addressed in the sprint.

Of course, you can’t make a general statement on how many tasks you should tackle per sprint, because this differs depending on the sprint length and sprint team. However, a good guideline is not to aim for 100 percent workload, but for maybe 80 percent. The remaining 20 percent will be filled by additional tasks during the sprint. After some time, you will experience that depending on the team or product, the 80 percent may still be too much or too little. Only experience can help here. If you adapt this value after each sprint for the next sprint, you will find out which value it suitable for your team.

And how do you plan your sprints? Do you still work with paper and pen? Or do you use Excel, handwritten notes or email? Perhaps you have already experienced that some points can get lost or chaos can quickly develop in this way. In the second part of our series we will explain you two different ways in which InLoox collaboration solutions can help you plan your sprints quickly and easily.

More about Scrum:

• Sprint Planning in Scrum (Part 2): How to plan sprints using the Gantt chart
• The Scrum Methodology
• Project Management, a Chicken and a Pig