There’s a lot of elements to consider when sprint planning.
- How will the work package be organised?
- How are the different stories to work on prioritised?
- How will the team remain focused on the sprint goal?
It can be easy to lose direction during sprint planning sessions. And when direction is lost, mistakes will very likely follow, which leads to further problems for the executive team, project management team the development team and of course the project itself.
Let’s look at some of the common mistakes that occur during sprint planning and execution and offer a few suggestions on how to avoid them.
Not setting sprint goals
Business success relies on goals based planning. A sprint planning session is no different. Setting a sprint goal can be the difference between a successful sprint and one that doesn’t meet expectations.
While it is tempting to dive right into each new sprint, tackling tasks without a sprint goal, this approach is a mistake. Without a clear sprint goal, your sprint plan will rarely yield good results. Without a sprint goal, teams can find themselves stuck, unable to progress away from trivial details, as if there’s no definition on what’s important for the sprint, then everything is as equally important and nothing tends to get done. And if the sprint plan fails, without a clearly defined goal, that sprint is cooked.
Sprint goals offer common direction and clear guidance for collaboration.
Sprint goals must be defined before each sprint, enabling alignment across all teams on this goal or goals. Once the goal is defined and communicated, execution planning can start.
Failing to create or maintain the product backlog
A product backlog is a list of tasks, in prioritised format/order, that need to be performed.
Product backlogs should receive periodic refinement to keep them as compact as possible, and clear for the delivery teams working on them. This refinement is called backlog grooming.
Backlog creation, and more critically – ongoing maintenance – requires discipline and commitment. Day to day tasks can easily become the focus, leaving backlogs to be forgotten about.
But, this discipline is mission critical for success. If a positive outcome is being sought, time must be scheduled to review and update a project’s backlog.
Backlog grooming enables sprint planning. Without it, this planning will very likely be unsuccessful and the sprint becomes jeopardised.
Velocity over quality
Falling for velocity over quality is a common mistake. Velocity is the number of story points completed per sprint. At the start of each sprint a team has (should) a solid concept of what can be accomplished and then at the close of the sprint, confirmation of what was accomplished. If more than was planned is accomplished, velocity increases. If less than was planned is accomplished, velocity decreases.
Keeping track of this over time is wise, as it allows for better sprint planning moving forward, offering solid insights into how many product backlog items can be achieved per sprint.
Danger arises however when velocity becomes the focus. Where the team becomes hellbent on accomplishing a fixed number of story points per sprint, rather than being focused on delivering high quality work.
Velocity over quality leads to bugs, which slows everything down overall due to rework, which impacts the project at large. Do not favour velocity over quality. Instead, determine what is realistic for each sprint given the complexity and size of each task and use this as your guide to what will be accomplished at a high standard, for each sprint.
And as a final point on this item, be conservative with this planning. Don’t over-commit. Allow room for learning and unexpected issues to pop up, giving space and time for the team to review each thoroughly and to tackle them with a quality based lens.
Outlawing changes to the sprint plan
Sometimes we encounter situations where the product owner/executive team/Client decide to add/remove items from the Product Backlog or change the priority of the items listed in the Product Backlog in the middle of a Sprint. Even though Scrum allows room for responding to change, any mid-sprint alterations should be kept to an absolute minimum and should not be tolerated unless critically required. Sprint backlog user stories must not be altered in the middle of a sprint except in the rare scenario something far-reaching emerges that can’t wait until the next sprint.
There are several negative implications on the Scrum team when a mid-sprint change is required. Mostly in such cases, the current Sprint will have to be stopped and a new Sprint will have to be initiated right from the Sprint planning stage. Time loss and product delivery delays also follow. Having said that, if the task is something of a top priority and cannot wait till the next sprint, then the team should have the flexibility to include it in the current Sprint if possible or kill the current sprint and start a new sprint.
Sometimes, it’s difficult, to near impossible to predict all of the challenges, urgent requirements, or unresolved bugs that might pop up during a sprint. Sprint plans can be changed, with good reason, only as long as the sprint goal isn’t compromised. And this should not ever become commonplace.
What matters most is that each sprint is completed with an outcome that meets the goal set during sprint planning.
Failing to be aware of sprint resourcing
Scrum teams use sprint capacity to define how many days each delivery resources will be available during each sprint.
When scheduling a sprint, be sure to confirm the resources available will actually…be available.
If you don’t confirm sprint resource capacity, delays are almost guaranteed to result, which will lead to a failure to achieve the sprint goal.
Remember, you can’t manage what you don’t measure.
You may not be able to predict how many resources you have with 100% accuracy, but if you’re aware of the factors that influence capacity, you can make better decisions about how many tasks your team should work on in a sprint.
Don’t try to boil the ocean
Sprints are finely tuned, time boxed delivery windows, hinged against resource capacity, prior planning and a sprint goal.
Avoid the desire to throw more and more into a sprint, hoping the delivery team will be able to achieve the increased load without losing quality, time or both.
By allowing your delivery team the opportunity to sprint plan, review the backlog, align resources, allow for unexpected bugs and challenges to arise during a sprint and to focus on delivering quality outputs, the end result will be rewarding.
Conclusion
Sprint planning is an essential part of any agile project, as it’s the time when the team gets together and figures out what they’ll be working on.
But with all the excitement of a new sprint, there are some things that can easily get overlooked in the planning stage, but which can lead to big problems later down the line.
The above should help on what to look out for so that you can avoid them when planning and then executing your next sprint.
