Here at Basis Technologies, we believe in the power of agile development and DevOps tools to revolutionize SAP workflows, so much so that we employ them ourselves when building our products. In agile development, projects are broken down into smaller chunks called “sprints”, and understanding how they work is a vital first step in achieving success with agile.

We realize that every organization is at a different place in their journey towards adopting agile and DevOps ways of working so we wanted to share a bit more of what it’s like to work in agile. We sat down with the Product Owner for our ActiveControl solution and asked him to share some tips on how best to plan an agile sprint in SAP.

Here’s what he had to say:

Part of my job as Product Owner of our ActiveControl product feels a little bit like Christmas….except that it comes every two weeks instead of once a year.

The reason for this is because here at Basis Technologies, we operate to a 2-week agile sprint model. At the start of each fortnightly sprint (two weeks for my American friends), I write my ‘Dear Santa’ letter to our Development Team. Or rather, we have a sprint planning meeting where I present the items at the top of the backlog that I would like to be delivered during the upcoming sprint.

A fortnight later, our Development Team presents me with the various gift-wrapped user stories they have delivered for me – or rather for our customers – at the sprint review meeting.

It honestly feels like Christmas came early every two weeks because without fail over the past couple of years while I have been the Product Owner of ActiveControl, my development colleagues have done a consistently great job of delivering improvements within each sprint that I know are going to give our customers increased value and ROI in future releases of ActiveControl.

This is certainly a far cry from the old ‘waterfall’ days that I remember from my years as a SAP Change & Release Manager in the dim and distant past where SAP projects often went on for 1-2 years before the customer (aka business end users) saw any changes (or value).

It is also a far cry from how many SAP customers are operating today, or at least a lot of the organizations that Basis Technologies works with. There are some impressive examples of large enterprises successfully transforming to agile in SAP. For example, this recent customer case study shows how a well-known global retailer moved from 3-monthly releases to 2-weekly agile sprints. And they certainly aren’t alone in delivering value quicker to their business. Other SAP customers such as Vistaprint, John Deere and IPG have all achieved successful agile transformations using ActiveControl.

One of the questions we often get asked by other SAP customers looking to emulate some of these agile successes is “How do we plan an agile sprint in SAP”?

In my opinion, the answer to this question is largely the same, regardless if it is changes to SAP, changes to ActiveControl, or indeed changes being done as part of any software development.

By following these five simple steps…

Step 1: Evaluate the Product Roadmap

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 the Product Owner to have the high-level vision of how to move the product forward. Are you really moving things forward against the Product Roadmap? Or getting overly distracted by short-term issues (or particularly vocal users)?

The first step in sprint planning and preparation is to decide/know where you want to be in 6 months, a year or even longer, not just after this next sprint.

Step 2: Have an Updated List of User Stories Before the Sprint Planning Meeting

Before the sprint planning meeting, the user stories that are proposed to be delivered as part of the upcoming sprint should be ready for wider Scrum Team review and consumption. This is the responsibility of the Product Owner since ultimately it is he/she that owns the roadmap and product vision, and by extension the prioritization of the Product Backlog.

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.

Step 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.

Here at Basis Technologies where we operate 2-week sprints, the planning meeting 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 organizations – and indeed within Basis Technologies 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 😉

Step 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 here at Basis Technologies and I am sure it is also true at our growing number of SAP customers that have already moved to more agile ways of software development.

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 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 and also – although I don’t necessarily like to admit it – ways in which I as the Product Owner can do things better to make the process run better.

Actually forget I said that – I am PROUD to admit it! It is only by acknowledging our own deficiencies and recognizing areas for future improvement that we as an agile team can collectively work to make future sprints more effective.

Step 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 and not dictated by 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 products, they also have to be the ones who pick what they contribute.

So those are the five topics that I definitely think are worth considering as part of sprint planning within SAP. Sprint planning forms an important part of agile development and is certainly something SAP-powered organizations need to spend time on as part of their move to more agile ways of software development.

And speaking of which, it’s currently 12:39 on Thursday, and I have my next sprint planning meeting in 21 minutes. Merry Christmas!

If you are interested in learning more about applying agile principles to your SAP environment, please contact us.