Skip to main content

Vertically slicing backlog items on a back-end COTS implementation

Last post 09:25 pm April 5, 2023 by Daniel Wilhite
2 replies
10:33 pm April 4, 2023

I have spent a lot of time reading up on the principles of scrum and feel fairly confident in the need to:

  1. Ensure the backlog item is vertically sliced (and delivers real business value when delivered standalone)
  2. Ensure the backlog item is small enough to be delivered within a sprint
  3. Ensure the backlog item is understood well enough by the PO so that they can effectively prioritise, discuss with external stakeholders, and communicate the value.
  4. Ensure the backlog item is not forced into a certain format (e.g. user story for the sake of a user story)

Whilst I understand the reasoning behind these principles, I am finding implementing them in practice to be nigh on impossible. The project I am working on is a highly technical project to implement a new order management system for a retailer. The project can essentially be split into two streams:

  1. Implementing the off-the-shelf order management system & doing all the required configuration (e.g. configuring the fulfilment workflows and logic, creating retailer accounts, setting up locations, product catalogue etc.)
  2. Building the middleware components that will allow the OMS to communicate with up & downstream systems i.e. interface the order from the eCommerce system to the OMS, communicate between the OMS and the payment gateway, pass the order from the OMS down to the WMS, interface pick / pack / ship updates back into the OMS etc. This is a highly technical workstream using Apache Kafka and building routers, mediators etc.

In the discovery period there was a significant amount of work to map out the order workflows, document all the happy & unhappy paths, discuss all sorts of business needs such as how to handle cancellations, how to handle short picks etc. I was not present for the discovery phase but have access to all these flows and notes taken.

I have joined the project in sprint 2 and as you might not be surprised to hear, the product backlog is a sea of highly technical tasks (which are almost impossible to understand to anyone who is not a technical architect or developer). These tasks are clearly all important and required to do things like setting up Kafka topics, building routers & mediators, configuring workflows etc. The trouble is, the PO is not really able to drive anything and instead it's the technical architect & leads that are writing all the backlog items, and then the BA's / PO are playing an admin role to get these tickets created in JIRA, categorised, put into sprints, estimated etc (but really this is all blindly following the guidance of the techies as the backlog items are too complex for non-techies). 

What I'm really struggling with is all these technically complex backlog items are clearly key chunks of work to deliver what is a highly technical product. I wouldn't question that as the tech leads are highly competent. And they clearly understand how all the backlog items fit together, sequence etc.

However my gut feeling tells me that the following things go against best practice (whatever that actually means):

  1. The backlog items dont appear to be vertically sliced and dont seem to deliver value to the business standalone. But really I dont see how this would be possible because the project isnt delivering any user functionality - and the integrations & OMS only really serve any value to the business / customers once they are fully developed/configured, and can be used to handle orders from the ecommerce store. 
  2. They are too technical to be understood by the PO/BAs, so it's very difficult to discuss with external stakeholders, or do proper prioritisation without just blindly following the steer of the techies. 

The customer placing their order online really is abstracted from all this complexity in the order management system, and really if you tried to write user stories from their perspective it would be pointless. They just want to get their order delivered by the date promised, and if cancelled they want to be informed and given a refund. Equally the internal staff never 'use' these integrations or OMS in a functional sense, they just rely on it working to route orders to the right place, orchestrate the workflows and manage / disseminate order updates to the right place. 

I dont want to get too hung up on how things 'should work', at the expense of common sense and what's right for the context of the specific project. But I just have this gut feeling that I'm completely missing something - and most importantly I'm trying to work out where I can add value as a BA that has turned up in this highly technical project. 

It seems ALL the resources online that discuss how to approach backlog items, slicing etc all seem to presume that it's software being built that is delivering functional features to human end users. In reality I feel this is a tiny proportion of projects. Far more common seems to be the implementation of COTS systems, often back end systems which require complex integrations with up & downstream systems, and which execute workflows in support of a much wider business process. These kind of projects never seem to be discussed online (at least not that i can find), and when they are, no one actually gives concrete examples of how they have managed such a project in an agile fashion. 

Any help for a confused BA would be much appreciated.



06:59 pm April 5, 2023

Far more common seems to be the implementation of COTS systems, often back end systems which require complex integrations with up & downstream systems, and which execute workflows in support of a much wider business process

What you've described doesn't sound complex. It sounds highly complicated with lots of interlinking parts that are largely well understood by technical people doing the work. Any significant unknowns were, it would seem, addressed satisfactorily in a so-called "Discovery Phase" and with little reason not to waterfall things out.

In your view as a BA, where is the innovation here? What are the risks and uncertainties which make this challenge truly complex, and having Sprint Goals which might mitigate them worthwhile? 

09:25 pm April 5, 2023

I agree with @Ian.  There doesn't seem to be a need for iterative delivery to gain feedback.  It sounds like a complicated plan to build something that is more dependent on tasks being completed in a specific order than on delivering usable increments of value.  I believe this would be better managed using waterfall Gantt charts. 

However, I do want to make this point with you.  In the use of User Stories, there is nothing that says the user has to be human.  A backend system can deliver to other systems and in that case the "User" of the backend system is the other system that consumes it's data.  You can write technical needs in a User Story format but it is not always efficient to do so.  I am an advocate of using the best method to convey the need and often that does not work in a User Story format.  As a BA working with a infrastructure, backend, or middleware product, you can be valuable if you focus your analysis on the needs of the systems that will be consuming the output of the systems you represent. 

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.