Feature planning in an agile SAP implementation

In one of our previous posts we talked about the core roles and basic team structure in an agile SAP implementation.  We are now ready to take a look at one of the first steps in planning the implementation and assessing the work that will need to be done by each team – defining the project features. 

A feature (aka epic or epic story) is the next level down from the overall project in that a single project contains one or more features. There is no black and white rule on what makes up a feature but here are some guiding principles that we try to utilize:

A single feature should take between 1 and 3 months to complete.  

By complete we mean – blueprint (gather the requirements via user stories), realize (configuration and development), unit test, prepare user guides and train the super users, and pass user acceptance testing. We do not typically include end user training and end-to-end integration testing in this definition as those are handled in a separate phase, typically towards the end of the project. 

A good starting point for many features are the standard SAP best practice scenarios.

Although some of those are too large and are often broken apart into multiple features. For example we often split best practice scenario 292 Sales Order Processing: Sale from Stock into 4 features – Sales Order Processing, Sales Pricing, Delivery Processing and Billing Processing.

Some features are business process centric while others are technical by nature.

Not every feature focuses on a business process. Some features are all about technology. For example, major technical interfaces with 3rd party applications are often big enough to warrant whole separate features be created for them. 

Keep reporting and ABAP development tied to business process features via user stories.

The only time you should consider splitting a particular reporting or custom ABAP development requirement into its own feature is when it is so large that it will take weeks to complete.  For example, this is often the case if we are talking about SAP BW reporting from a brand new InfoProvider that will require considerable BW back-end development to accomplish.

Create features for 100% of project work to be done.

If possible, don’t exclude any work from being managed through features.  Here are some examples of features that you should consider including:

• Feature identification and planning
• Material master data conversion
• Wireless network deployment at a plant
• End-to-end integration testing cycle

The end result of a feature identification exercise is a list of features that represent the entire project.  It is very common for some of the features to go away and others be introduced throughout the project, which is perfectly fine.  You just need to make sure that the key project sponsors and decision makers are aware of when that happens and what that means to the project costs and timeline.

Here is a sample of features for a hypothetical SAP implementation project utilizing Target Process, the tool we use and train our clients to use to manage their technology projects:

Once the initial list of features is identified we can move on to sequencing the features – identifying the order in which features should be worked on.  We are not concerned about duration or timeline at this point, just the order of work.  Normally, we have each team take a first pass at sequencing their own features and then have the project integration manager (aka solution architect) use that as input to build the final global sequence.

Now that we have the features identified and sequenced we are ready to work on building a feature timeline.  This is by no means required, but most of the time some type of a project timeline is requested for reporting on project status and progress to upper management, so realistically a timeline is something that we have to put together on most of our projects.

Generally speaking we try to have as few features active at any given point in time as possible.  The idea is to follow some of the core principles of Agile and Kanban – focus and limit work in progress.  So most of the timelines we put together have only 1 or 2 features that are actively being worked on by each team.  The duration of each feature depends on a number of factors, with complexity of a feature and size of a team having the most impact.  Ultimately, we use a “magic formula” of input from the teams, our past experience and gut feel to come up with a duration for each feature and plot the features out over time.  The end result can look something like this:

Couple of important items to note about feature planning:

You will never have a perfectly sequenced feature timeline that will satisfy everyone.  

This is simply not possible to achieve without doing only one feature at a time across the entire project, which certainly doesn’t make sense.  So build a timeline that is “good enough” and move forward.  Old requirements will change, new requirements will come to light and thus the timeline will need to change throughout the project.  Accept this fact and learn to adapt to changes as opposed to fighting them.

We strongly encourage only doing sequencing and timelines at the feature level.  

That should be plenty to satisfy the project monitoring and reporting requirements for upper management.  Do everything you can to stay away from doing sequencing, dependencies and timelines at the user story or god forbid task level.  In our experience, this results in nothing but wasted time, additional overhead and bureaucracy for the entire project team with no value in return.