Steps to better Agile Sprint planning?
In the company I work for – we develop to fortnightly (ie every 2 weeks) Agile sprints. As Product Owner – I sit down at the start of each sprint to plan out what our Development Team will include in the upcoming sprint.
Here are five topics that I think are important to achieve better Agile Sprint planning:
#1 Evaluate the Product Roadmap constantly
An agile sprint is aimed at delivering improvements to software applications quickly. Regardless if that sprint is 2 or 3 weeks (or even 4 weeks, which is the generally accepted upper limit for an agile sprint), the outcome at the end of the sprint should be a product increment that is usable and releasable.
It is important to note that this doesn’t mean that something necessarily needs to be released to users in Production at the end of each sprint; clearly it would not always be possible to do this in the world of SAP.
The responsibility lies with me as Product Owner to have the high-level vision of how to move the end product forward. It can be an extremely fine balance between moving things forward in each sprint against the roadmap, whilst not getting overly distracted by short-term issues (or particularly vocal users!).
#2 Have an Updated List of User Stories Before the Sprint Planning Meeting
Before the sprint planning meeting, the user stories that I want to propose for inclusion in the upcoming sprint need to be ready for wider Scrum Team review and consumption.
Personally, I also like to have a rough estimate of time and effort to complete each of the items that are prioritized near the top of the Backlog.
This not only helps to determine what actually might be achievable as part of the next sprint, but also helps the Scrum Master and me as Product Owner effectively manage the overall budget and timeline of the project.
#3 Meeting Arrangements
Sprint planning meetings are timeboxed to a maximum of eight hours for a one-month sprint. For shorter sprints they are usually shorter.
In our organisation, usually takes 1-2 hours. We have it every second Thursday at 1PM on the dot.
The Agile Manifesto talks about how “Consistency reduces complexity and thus optimizes predictability,” and I can definitely relate to that.
In the virtual team setup found in many SAP-run organisations – and indeed in this post-pandemic world where most of us are working from home – I think having the sprint planning meeting at the same time every time increases the chances of the Scrum Team turning up on time.
Or that’s the theory at least 😉
#4 Utilize Data and Expertise to Continually Improve Sprint Planning
As SAP teams get more experienced in delivering Agile, data can help drive future behavior and success at sprint planning. This is certainly true in my own experiences.
Based on the knowledge and experience gained from previous sprints, our Scrum Master, Development Team and myself now have empirical information on how long previous user stories actually took to deliver versus the story points they were initially estimated at. We also have a much better idea of what individual developers might be able to achieve in future sprints based on what they delivered previously.
Sprint retrospectives also play an important role as part of the process of improving future sprint planning. This meeting at the end of each sprint helps identify ways to increase quality and effectiveness across the team (myself included!)
#5 Collaboratively Plan the Sprint Backlog
The sprint backlog is the list of user stories that are predicted to be delivered as part of the upcoming sprint to achieve the sprint goal.
The sprint backlog must be planned collaboratively across the team, and not dictated by just the Product Owner (or the Scrum Master).
The team must choose the sprint items and the scale of the sprint backlog collectively. Since they are the individuals who contribute to the fulfillment of the product, they also have to be the ones who pick what they contribute.
So those are the five things that I have personally found to be really important in planning better Agile sprints.
Would love to hear what works for other people out there to achieve success in Agile for SAP.