As a Scrum Master and Agile Coach, every day I deal with issues that result from lack of understanding the basic rules of Scrum. Its principles are often misinterpreted. For the sake of both clients and team members, it’s worth to dispel some of the most common myths of Scrum planning and estimating.
Myth 1. Estimate equals commitment
Project Managers who have no experience with Agile software, but do have a background in waterfall methodologies tend to confuse estimate and commitment. Let me define the difference between those two. Agile estimate tells you how much the team hopes it will take them to get the job done. The Sprint Goal defines the team’s commitment. It tells you what the team promises to deliver during upcoming Sprint as an Increment.
Myth 2. Spring Goal is optional
Sprint Goal is essential to the success of the Sprint. There are several reasons for it. First, it is the team’s commitment. Second, it defines whether the Sprint was a success or not. Third, and most important, the Sprint Goal is the Guiding Thought for the team. Especially if things will not go as expected.
Myth 3. You cannot modify Sprint Backlog after Scrum Planning
The Sprint Backlog is a plan of how the team wants to reach the Sprint Goal. As new things are learned about the project, the product, and the requirements the plan will need to be changed and adjusted to meet the Sprint Goal. Changes in the Sprint Backlog can be made by the team and only by the team to keep to the plan.
Myth 4. You can predict all tasks for Sprint during Planning Meeting
There is an ultimate law in all software projects: “There will be changes.” The team and the Product Owner won’t predict all possible options prior to or during the Sprint Planning. This emergence occurs as the team works through the plan and learns more about the work needed to achieve the Sprint Goal.
Myth 5. Work is assigned in Sprint Planning
Adjusting to changes is the essence of Scrum and Agile. If every team member has all the tasks assigned during the Sprint Planning, they are not able to respond to changes. If unexpected tasks come up during the Sprint or someone is underperforming the workload cannot be flexibly distributed among other members of the team and the Sprint Goal will not be achieved.
Myth 6. Development Team doesn’t have to prepare for Planning Meeting
It is a common and very harmful practise that the Sprint Planning is the first time that the Development Team gets to know the User Stories that the Product Owner wants them to deliver in an upcoming Sprint. The Development Team has to estimate them ad-hoc, without a deeper understanding of the problem. This usually leads to drastic changes during the Sprint when new aspects of the User Stories are discovered.
Myth 7. Entire Sprint backlog must be decomposed during Sprint Planning
It is also a common practice to decompose the entire Sprint Backlog to small tasks and then estimate each of them individually. The main argument for the advocates of this method is that this is an optimal way to fill the Sprint Backlog to its maximum capacity without exceeding it. The problem with this approach is that there is no room for any adjustments. It is not only about the plane number but also about the gut feeling of the Development Team of what they can commit to.
Myth 8. The purpose of estimating the remaining work is to get a specific amount of time needed to finish the project
Estimating how much work still needs to be dealt with is important to the success of any project. However, Agile estimations bring a lot more value than just giving a scale of time needed to deliver the project or functionality. In the planning process, there are many discussions between the Development Team and the Product Owner. This allows them to identify all areas that require more insight or that might have been overlooked. Estimating Task and User Stories is also a great way to help the Development Team learn and understand those items in the same way.
Myth 9. Product Owner can be replaced with proper documentation
The Product Owner’s presence is mandatory during Sprint Planning. There are several reasons for it. Firstly, the most effective communication method is a face-to-face conversation. In many cases, written documentation can be interpreted in more than one way. It is the Product Owner’s responsibility to correct all misunderstandings. Secondly, even the best documentation in the word will miss at least one important detail. And the Product Owner is usually the only person who can make a final decision regarding that detail.
Myth 10. There is a right size for a User Story
There isn’t, actually. Every Development Team is different. Every project is different. Technology stack, team experience domain knowledge and every other little things that add up to the specifics of the project will make a difference. There are two rules for a User Story:1. It should be small enough to be delivered during a single Sprint. 2. It has business value in its own.
- It should be small enough to be delivered during a single Sprint.
- It has a business value of its own.