Predictability is an important factor when you work in a complex environment. It helps to come up with a better forecast. If the Scrum Teams cannot maintain the predictability, eventually forecasting becomes challenging. If the Scrum Teams cannot complete the work that is being pulled into a Sprint by the end of the Sprint, eventually it leads to unpredictability. This article helps you to know some reasons for the spill over of the work in Sprints. 

Let’s analyse some of the common reasons for the spill over in Scrum teams.

 

Developers choose more than their available capacity

If the Developers do not have a fair understanding on their available capacity (public holidays, Personal Time offs, people spend on outside Sprint work such as participating in organizational activities such as hackathons) they may end up pulling more work than their available capacity. The Scrum master has to help the Developers understand the availability of their capacity during the Sprint planning and accordingly encourage them to forecast the amount of work for the Sprint.

 

Unplanned interruptions during the Sprint

In a complex environment, it is inevitable to get some unplanned work such as critical product issues or urgent change requests and so on. If the Developers plan their 100% capacity for the work during the Sprint Planning, and in case there are some urgent unplanned work has to be attended, then it will impact the planed work. So, it is better to keep some capacity reserve for such unplanned work (example: 10%). In case there is no unplanned work in a Sprint, the Developers can always pull further work within the sprint.

 

Non collaborative environment

Sometimes the Developers try to work on individual Product Backlog Items within a Sprint end to end. It leads to silo based work and also poor transparency and dependency because the individual Developers do not pay attention to other member’s work. Encourage the Developers to work on one item as a group for example one UI developer, one programmer, one Database developer and one tester.

 

No or Poor Definition of Done

Many a times Scrum Teams do not give importance to a strong Definition of Done. Either they don’t have a definition of done or it is a weak one, which doesn’t enable translucency because of which changes keep coming throughout the sprint. Have a strong definition of done that is displayed in such a way that all the Scrum Team members can easily view it helps in creating potentially releasable increments with expected quality will help.

 

Improper Product Backlog Refinement

Scrum recommends to keep few items in your product backlog ready for the sprint planning that can be pulled easily into the Sprint Backlog. If the Developers are seeing the Product Backlog Items for the first time in the Sprint Planning, it leads to poor planning. Scrum Master has to recommend to have at least one product backlog refinement session every Sprint. General recommendation should be, if the team’s velocity is X story points, then it will be good to keep at least 2X worth of items refined in the Product Backlog.

 

Poor Sprint Backlog Management 

Sprint Backlog is the Developers’ planning and tracking artefact that helps information radiation. In general most of the teams don’t keep the Sprint Backlog up-to-date based on the current status of the Sprint Backlog items. Having a team working agreement encourages to keep the sprint backlog to reflect the latest status always. Perhaps every Sprint one person in the Developers taking the responsibility of the Sprint Backlog updates increases the team’s responsibility. This can be done on a rotation basis.

 

Dependencies 

While working in a multi-team Scrum setup, it’s always challenging to deal with dependencies. Instead of managing the Dependencies try to eliminate the dependencies as much as possible, if not possible try to reduce the dependencies. Joint product backlog refinement, upward, downward dependency identification, same team handles the related items instead of giving to different teams will help to address the issue of inter team dependencies. A Scrum of Scrum meeting with a frequency of twice a week will also help to manage the dependencies effectively.  

 

Lack of focus on the Daily Scrum 

Daily Scrum is a powerful inspect and adapt opportunity for the Developers to inspect the progress towards the Sprint Goal and adapt the Sprint Backlog. If the Developers treat this as any other general meeting and if they skip it or treating as a status meeting, they may not be able to meet the Sprint Goal. Scrum Masters should encourage the Developers to self-manage during the Daily Scrum and also create an impediments board to highlight and manage them effectively. 

 

Unavailability of the Product Owner

Most of the Scrum Teams feel that the Product Owner is not required during the Sprint after the Sprint Planning. This leads to delays or making assumptions by the Developers. When the Developers need some clarifications, if the Product Owner is unavailable, they go ahead with some assumptions and if they are wrong then the Product Backlog Items may not be accepted. Scrum Masters should encourage Product Owners to be available daily for some time to the Developers to clarify their queries, assumptions and also to test the work done by the Developers. This not only speeds up the work and also creates a good rapport between the Developers and the Product Owner.

 

Lack of inspect and adapt

Scrum is all about inspect and adapt regularly. The Scrum Teams should have proper validation of the processes, tools, practices, communication, collaboration and so on during the Sprint Retrospective and continuously improve them to become better. That is how the Retrospectives make good teams great teams.