67% of all DxPathfinder Agile assessments have indicated sprint planning is an issue.
I have been working with agile for 20+ years and have seen teams struggle and teams where everything flowed like a river. While each team may not have adopted 100% of the official methods, the ones where it worked generally found a Way of Working that, well, worked well for them.
Many have the perception that agile is all responding to change and no planning. That is far from the truth. Each sprint is responsive to change but change within a sprint is very disruptive. Often this change is not imposed externally, but arises internally due to poor planning.
While there are many factors that can derail a sprint, some common ones are:
Now let’s look at each of these in more detail.
While it is ideal to have a support team segregated from the development team, this isn’t always possible and it is inevitable high priority support requests will “pop-up” requiring one or more of the sprint team members to jump in.
Failing to plan for support activities during the sprint planning process leads to several negative consequences.
Neither outcome is good and ultimately damages team morale and customer satisfaction.
What I recommend is to plan for the unexpected. Leave some capacity in the sprint plan for pop-ups. If there are no urgent support requests, the extra time can be spent on learning & development, testing, or god forbid an unexpected happy hour 🙂 Or (I know this is against the rules) add an extra easy item to the sprint from the backlog.
Secondly I recommend prioritizing quality over quantity of new features. Building a system is like building a house. Adding new rooms on top of a weak foundation may work in the short term but ultimately slows you down and weakens your team's reputation.
Last point - have a common team understanding of the priorities (support or sprint delivery). The important thing is to protect and build teamwork and team confidence. Consistently resorting to over-time is unhealthy and unfair.
In an ideal world an agile team is composed of interchangeable team members. I don’t know about you, but I have never lived in that world. Not only do teams have a blend of senior and less experienced technical resources, but also a mix of resources with higher degrees of specialization in different areas. For example:
Obviously there are many different combinations of skill sets and experience levels and it is very rare that everyone can do everything equally.
The first thing is to know your available capacity by skill & experience level. This should be taken into consideration when planning. While analyzing business requirements and decomposing them into actionable items, also note the skills & experience level required.
Ideally work items / tickets are selected for inclusion in the sprint not only based on the business objectives, but also to optimize resource utilization. For example a combination of easy & complex requirements distributed across experience and junior resources ensure you aren’t using your most experienced (and most expensive resources) to do simple things. The same logic applies to front-end & back-end development, functional & highly technical.
The objective is to not overload any one team member but distribute work across all team members as evenly as possible. Optimizing total team output requires optimizing workload at the individual level.
Too often items are picked from the backlog without fully understanding, in sufficient detail, what is required. Business requirements are like icebergs. There is always more to it than what you see on the surface. Many times items are included prematurely into a sprint with the thinking “we’ll figure it out during the sprint”. While doing some analysis in the sprint is normal, this should be minimized where possible.
Very simply for each requirement you must know, in detail,
What I have seen work very well - and again this may be unconventional by standard agile standards - is to maintain two backlogs:
However you do it, the important thing is to not underestimate the complexity of any requirement. Know what is expected and more importantly everything required both functionally and technically to deliver it BEFORE assigning it to a sprint.
Discipline and self-control are critical. All too often we bend rules & cut corners trying to make stakeholders happy which usually results in no one happy.
Are support/maintenance activities accounted for in the sprint plans?
Are work items (user stories, tickets, etc) well distributed across the team?
Is sufficient design (functional & technical) done to accurately estimate effort prior to assigning stories to sprints?
Sprint planning is one of the dimensions explored in the DxPathfinder Agile assessment.
