The Importance Of Sprint Planning

Sprint planning is the first ceremony in the SCRUM cycle. I’ve seen varying implementations of sprint planning depending on the client I’m working and often it works very well. Occasionally however, I have worked with clients where the entire team including the management decide to prioritize it under everything else.  For me this just screams tragedy, so here comes my perspective on the importance of sprint planning.

Wait…I thought I was the striker?

A team without sprint planning is kind of like a football team without a tactics drill session and game strategy.  You could knock a team together, buy the kit and then when it comes to the first game everyone is running amok the entire time.  I’ve seen this happen in scrum teams.

Dedicated time assigned to planning allows the team to focus on the business requirements. This is the time where gaps in requirements are raised, misunderstandings are brought to the surface and most importantly solutions are created as a team.

Let me just get on with it

Often without planning, developers will start coding immediately in isolation without taking into consideration the other in-progress user stories.  Potentially these clashes don’t appear until much later in the sprint and then there is a rush to refactor code conflicts and address requirement conflicts – This increases exponentially when there are more dependencies between stories.

Isolated developers will also create solutions using patterns best suited to their experience.  If not agreed upon within the planning session, you will find similar & related business requirements implemented in several different ways. These can result in increased code duplication, complexity in refactoring and adding to technical debt.

Suck it up princess

From a moral perspective, sprint planning is an excellent time to get the team on the same page.  The team decide which user stories are committed to the sprint – not the lead developer, not the product owner…the team.  The sprint is delivered as a team,  so commitments must be made as a team.  By allowing the team to decide what can be delivered will give a sense of responsibility and ownership.  I have often found teams that feel this, will achieve more and higher quality.

Some managements will try and push more into the sprint at the beginning and this only creates negative feeling and lack of control.  The team must feel the committed stories are achievable else efficiency will suffer before the sprint has even started. Remember more back log items can always be added to the sprint if the team is achieving and capacity across all roles is there.

Incomplete work from the previous sprint can also tempt developers to skip the session in the following sprint.  Not only will they have to play catch up in term of understanding the requirements, they will also lose their participation in estimates and any valuable experience they have gained as an individual will not be available to the rest of the team whilst solutions are being discussed.

Why don’t we try

Sprint planning is a part of agile and that in-itself should be subject to constructive criticism. If you find your current way of planning isn’t working then discuss the problems and draw actions from them. Does the product owner or scrum master need to attend the entirety of the session? Can the session be split up into parts? Maybe the PO and BA can spend the first hour discussing the user stories so that the scrum team can be left to work out the solutions and task breakdown.

Implementing UAT into Scrum

Definition of uat

User acceptance testing is an a process that validates the deliverable conforms and meets the business requirements initially laid out.


Proposed Agile Process with UAT

Support Process - Support Process (1)

This proposal introduces a period of time after the sprint has ended to allow for UAT. It provides business analysts, product owners and stakeholders to look at the feature before going live on to the production website.

This also gives them the opportunity to raise bugs which we can triage and categorize into either an immediate hotfix or to be put into the backlog.

Current Issues & resolutions to those by using the proposal


Testing within the sprint


The awaiting approval status within the sprint against user stories is effectively forcing business analysts to perform UAT within the sprint.

This caused numerous problems because the features crossing multiple stories were being tested and bugs were being raised despite the entire feature not being complete.

Additionally business decisions were being made within the sprint without the knowledge of the product owner or stakeholders.


Introducing UAT after the sprint ends allows not only business analysts but the product owner and stakeholders to look at the features together once we have declared them as finished.

We will only release completed features for UAT once the develop team has completed all user stories associated with that feature and are satisfied any major bugs have been resolved.


Stakeholder Involvement


Features were going straight into LIVE without allowing the stakeholders to accept with them first.

There were numerous example of the SCRUM team developing features against user stories but once going live, the stakeholders raised complaints about missing components or incorrect assumptions. The scrum team then had to work on hotfixes within the active sprint and forced us to drop some user stories.


Any bugs found within UAT and are deemed critical should be raised as a P1 within the active sprint. They must be worked on immediately on a hotfix branch.

25% of the active sprint time should be allocated to each team member to allow us to fix any issues raised from UAT.


Technical Actions needed to adopt the proposal

We will now need to extend our use of development branches in order for the proposal to run smoothly.

In addition to our current workflow with branches we will now introduce Release branches.

These are created from the develop branch and represents the latest code ready for UAT. This will happen at the end of the sprint. Any left over work will require the developer to work on this branch and allow other developers to work on the develop branch for the next sprint.

Bug fixes are worked on this branch. They can be re-merged into develop at any time.

If accepted then it is merged into Master ready for deployment to Production.

The Master branch is also tagged for future reference.