Why Does Sprint Planning Fail?
Sprint Planning is one of the most crucial stages of product development as it lays a foundation on what the team has to accomplish throughout the Sprint. However, many team members may feel Sprint Planning is like being held hostage as nobody is allowed to leave the room until they figure out the Sprint Plan. The team has to be sure that all the risks and uncertainty are eliminated and the Sprint is ready to be started. Most of the Developers feel that they can just start the coding and get done with the feature that has to be completed. However, if you take an analogy of a student writing an exam, an average student just glances at the question paper and starts writing the answers. But a clever student would first read thoroughly through the question paper and then plan the time on which he/she will write answers. Sprint Planning could be imagined in a similar way, where Developers want to get started with the work and effectively plan the increments that have to be delivered through the Sprint. If most of the Sprint Planning is carried out in such a manner, then there is a fair chance that Sprint may fail and the Developers would fail to keep up their promise. This article focuses on various reasons why Sprint Planning fails and how it can be avoided.
What is Sprint Planning?
The new Scrum Guide 2020 has updated the way Sprint Planning works and has described it as a plan that initiates the Sprint by laying the foundation for the Sprint. This plan is created by the entire team together and ensures everyone has clearly understood their role in the Sprint. The Product Owner makes sure that the team members are ready for discussing the Product Backlogs and how they are going to align the Sprint Goals with the Product Goals. Sprint Planning may also take place in the presence of stakeholders who may pitch in some ideas of what tasks should be completed. The Sprint Planning mainly addresses three questions given:
- Why is the present Sprint valuable?
This question answers how Sprint would increase the value and utility of the product. The entire Scrum team pitches their opinions and makes a list of why the present would be valuable for the stakeholders. Here the Scrum team also finalizes the Sprint Goal before the Sprint Planning ends.
- What are the features that can be done in this Sprint?
The Product Owner and the Developers collaborate to analyze the features that could be completed in the Sprint. It is made sure that they do not overestimate or underestimate the amount of work that is allotted to Sprint. These items are listed reviewing the past performances using the burndown chart and also by individually making the Developers accountable for the work they would finish by the end of the Sprint.
- How is the chosen work going to be completed?
Every selected Product Backlog item has a plan which has to meet the Definition of Done. This is done during the decomposition of the Product Backlog into smaller items which may take one day or less to complete. It is all dependent on the Developers to decide how they are going to turn the backlog items into increments. The Sprint Backlog consists of items from the Product Backlog along with the plan of how these items are going to be completed. For a Sprint that would take a month to complete, the maximum amount of time for the Sprint Planning would be eight hours. Likewise, if the Sprint duration is less, the event is shorter.
Sprint Planning Dysfunctions
Now that we have understood how Sprint Planning works, let us look at a few most common reasons or mistakes that lead to the failure of Sprint Planning.
1. Not defining the Sprint Goal
When a team does not define the Sprint Goal accurately, it makes the path of the Sprint blur and the team members cannot plan their schedule accordingly. The Sprint plan made by the team would surely fail as there is no clear destination as to where the team has to head. The Product Owner has to start the Sprint Planning with a clear Sprint Goal such that the entire discussion only focuses on the three questions given in the updated Scrum Guide. If the Sprint Goal is not decided before the meeting or is kept till the end of the meeting, the entire subject turns towards the objective of the Sprint rather than discussing how to finish it. The Sprint Goal promotes teamwork and promotes flexibility and focus. The agenda of the Sprint Planning should be to start with a Sprint Goal and decide the number of tasks that could be completed and finalize it
2. Planning the Sprint in detail
Many professionals may argue that a meticulously planned Sprint would yield better results than a Sprint planned with the time constraint. However, the opposite is true as the team does not have many ideas at the beginning of the Sprint, so researching and estimating time for completing tasks is all in vain. A perfect plan does not exist when planning in a complex environment. The teams should settle for Sprint plans which seem good enough to get the job done and as they learn more about the items during the Sprint, they could improve the value given to the Product Increment. The team should add more details as they discover more about the Product or Product Backlog items that they are working on.
3. Focusing only on the velocity and story points
Many teams give way too much importance to the velocity and the story points where they aim to increase the points compared to last time. When the team tries to overestimate the work for a Sprint by trying to aim for completing higher story points, the members may burn out and can fail to complete the tasks in the Sprint. The team was focusing more on completing the story points but was not bothered about making the workflow from left to right. The team should under-commit during Sprint Planning and should leave room for unexpected events. This would help the team to collaborate better and if the work is over sooner than expected more work could be added based on the time remaining. Under-committing will also prevent work from getting carried over to the next Sprint.
4. Planning the Sprint too rigid
When the team believes that the items on the backlog have to be completed and changes are not allowed, there could be undue pressure on the Developers to complete the work. This would make the Developers cautious during Sprint Planning, which would make them waste their time planning their Sprint such that they make it perfect. This time wasted could be used to develop instead of plan, hence, the Developers should be given the flexibility to introduce changes between the Sprint such that they could work with peace of mind. The team could also be given the freedom to add items or remove items on the Sprint Backlog based on the things that are learned during the development process.
5. Do not plan important features because of uncertainty and fear of failure
The most important feature of the product could not be developed as easily as it may seem because, often, the Developers are not sure about their path or how they should proceed. The team is feared about the feature being a failure if they are unable to deliver value. The product could undergo few spikes such that the feature works in the future. However, spike refinement cycles cannot be used if the product is really valuable and time-to-market is essential. It is important for the Developers to feel safe even if they fail so that you can earn their trust. This makes them take risks and ultimately helps them to build the most valuable thing for the product. The team has to just get started and start discovering and tackling the impediments as they develop. If the feature is an important one, it is better to start the process than waiting for the planning to be perfect. When the team works on difficult features at the beginning, they get more time to analyze the solution for the issue. Setting smaller and attainable Sprint Goals goes a long way as it makes the work of the team's task easier. The higher the risk is for a feature, and the more important a feature is, it is better to start the development earlier.
6. Not appropriately handling the carry overwork
There are chances that there would be unfinished work when the Sprint ends. This work gets carried over to the next Sprint where the members waste their time trying to re-estimate backlog items. There may be 20% of the work remaining from the last Sprint which would take time as much as 80% of the work. Hence, it may be feasible to assess the quantity of work remaining. The team members can tackle this by overestimating the amount of work remaining rather than underestimating them. This means the team can carry over the entire story point for the remaining work and does not have to spend time calculating how many story points the work is worth. As you can add more items at the end of the Sprint, this approach seems the best way to handle the carry-over work which can save a lot of time. Of course, if the team has a better way of handling it, they can carry on. The main aim is to know the way to handle the carried-over tasks such that the team member's time is not wasted.
The main aim of planning a Sprint is to reduce the time consumed during the development process and lay a path which the Developers have to follow to reach the Sprint Goal. When a Sprint fails, it is better to analyze these points in the retrospective and correct it in the next Sprint. Assessing and analyzing the issues that are causing Sprint to fail is the key to prevent Sprint Planning to fail.
Conclusion
Sprint Planning is one main Scrum Event that lays the groundwork for the Sprint to begin. The entire team is expected to be present at the planning meeting as the Product Owner discusses the agenda of the upcoming Sprint and the team members decide what work has to be done for the next Sprint duration. Sprint Planning fails when the team does not consider Sprint Goals or may keep the Sprint Goal as an afterthought. Induce flexibility in the Sprint and encourage the team to take risks while developing important products. When the Product Owner or Scrum Master cannot handle the impediments faced by the team, the Sprint is more likely to fail. Also, when the Product Owner makes the Sprint rigid with no considerations for changes, the Sprint may fail as Developers spend more time planning than working. Noticing and avoiding all of these points while working on your next Sprint Planning, would yield results and make your Sprint Planning a successful one.
References
- https://www.scrum.org/resources/what-is-Sprint-planning
- https://www.scrum.org/resources/blog/what-failed-Sprint
- https://medium.com/serious-scrum/6-common-mistakes-when-planning-a-sprint-6fedbedf604e
Useful Links:
Leading SAFe Certification Copenhagen, Product Owner Certification Course Coimbatore, A-CSM Course Training Paris, Scrum Master Certification Course Melbourne, Product Owner Course Doha, Certified Scrum Product Owner Training Anchorage, CSM Certification Training New York City, Certified Scrum Product Owner Online Training Berlin, Scrum Master Virtual Training Course Coimbatore, Product Owner Training Austin
