Every Sprint starts with a Sprint Planning event. It is very crucial to ensure that the Scrum Team comes to a shared understanding of what and how are they going to deliver a “Done” increment that creates maximum business impact. Although, like other events Sprint Planning also is often marred with few dysfunctions. In this post I will bring forth 5 common dysfunctions that I have observed associated with this event.
n
Unavailable Product Owner:
nn
Product Owners often tend to think that their job is to pass on the requirements to the Development Team and that is good enough to get the work done. They spend too much time with the end-customers, stakeholders or just writing detailed requirements for the team. On the other hand they spend too little time with the team and are mostly unavailable to the team when they are needed the most. This leads to the most common dysfunction – unavailable Product Owner which percolates to other dysfunctions.
nn
Lack of Refinement:
nn
Since Product Owner is often unavailable, the development team skips the Product Backlog Refinement sessions. As we are aware, Product Backlog Refinement is a collaborative session where the Product Backlog Items are refined and moved towards the ready state i.e. detailed enough, ordered and estimated. Ordering of Product Backlog Items is accountability of the Product Owner, as well as providing enough details around any Product Backlog Item is job of the PO. Now, since the PO is not available then the refinement doesn’t add any value.
nn
Ambiguous Requirements:
nn
As enough time is not spent in Product Backlog Refinement, the development team sees the requirements for the first time during the Sprint Planning. Since, refinement has not happened these requirements are often vague and ambiguous. The development often does not have clue how to move forward. They spend lot of time going over and over a single PBI and thus not making use of the Sprint Planning event to Inspect and Adapt for the Sprint.
nn
Erroneous Forecasts:
nn
Since the team sees the PBIs for the first time during the Sprint Planning, they often do not have any clarity of how to approach the requirement, or they often overlook scenarios/complexities that may arise as they start implementing the requirements. As a result, the estimates provided by the team are either overestimated or underestimated. This in-turn leads to erroneous forecasts of what can be done during the Sprint or thereafter.
nn
No Shared Commitment :
nn
All the above four dysfunctions lead to the final dysfunction which is No Shared Commitment within the Scrum team. As the requirements are vague, the forecasts over/under estimated and there is no shared commitment within the Scrum Team, a tiff starts between the business (Product Owner) and delivery (the Development Team). A game of pointing fingers and highlighting what other has not done or could have done begins. None of which is conducive for the team to work as a cohesive unit.
nn
Conclusion:
nn
There might be many more dysfunctions that might lead to not having a successful Sprint Planning event. These are few that I came across. As a Scrum Master it is always good to be vigilant about such dysfunctions, reveal them and help the team to overcome the dysfunctions.
