Having supported dozens of teams as a Scrum Master, RTE and Agile coach, I find that teams consistently fail to perform adequate sprint planning.

According to the Scrum guide, at the end of the Sprint planning “Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.”

What could go wrong with that?

Scrum is a system, and as such the garbage collected on one stage gets multiplied and carried over to the next step. In the continuum of Backlog refinement > Sprint planning > Development, poor quality at any stage carries to the next one, driving eventually to the sprint goal failing (more on sprint goals later).

To illustrate: stories that haven’t been refined and aren’t “ready-ready” are going to generate questions by the development team during the sprint, which will delay the execution. Work done in development of stories that are not clear (if the team doesn’t ask for clarity) will result in stories that are not approved during sprint review, and so on.

Furthermore, as most teams find it cumbersome (and it is) to create subtasks and assign time to them, many teams don’t do it. The result is that during the Daily Scrum it’s impossible to see any measure of progress and the delays get unnoticed for too long, contributing to the sprint failure.

Regarding the Sprint goal. When was the last time you saw a Sprint goal? How “goally” was the goal? Most new teams I worked with didn’t understand the motivation that the sprint goals brings to the table and don’t take it seriously. Same goes for many busy product owners that throw their hands in the air screaming, “for as long as I get something!!!”.

Of course there are mature teams that do have sprint goals, and do plan carefully, but it takes experienced Scrum Masters and a lot of time to get to that point.

Seeing all these issues, and the need from organizations to get to higher levels of maturity sooner we developed Agile planning for Jira, the first product on a suite to help teams doing Scrum at scale.

Divim’s Agile planning for Jira uses forcing functions to help the team focus on sprint planning consciously considering information relevant to it (for instance, when the team is going to start a sprint, they are presented with the Sprint goal field and the sprint dates), but that’s not all.

Designed with Lean principles in mind, Agile planning for Jira reduces the number of actions needed for the team to complete the planning breaking down the work in units of one day or less. This enables each team member to create their subtasks and assign estimated times in a seamless way, driving planning quality while reducing the effort necessary to achieve that quality.

The second design breakthrough is that with Agile planning for Jira the teams can see their current allocation compared to the planned team capacity for that sprint. Creating a team and assigning planned capacity for each team member is also simplified. There is no need to change screens or go to different places to do any of this. It’s all on the Sprint planning screen.

Finally, as the team loads the sprint, Agile planning for Jira adds up the story points and it shows them against the past velocity of the team. We provide the velocity of the past sprint and the average of the past 3 sprints, to allow the team to make better decisions with all the information needed at hand.

Have your team try today free for 30 days Agile planning for Jira and give us your feedback.