The smell of a single product backlog when working with service based architectures.

Easily the most common issue I see when trying to optimise an organisation for delivery is that of the lack of an identification process for multiple products that exist within the software architecture.

Agile doctrine states that all stories must be end-user facing, but nearly all scholarly articles are only covering a simplistic application, not the service based architectures which are pretty much the norm if you're looking for scalability and stability in the enterprise. Product Owners are taught to adhere to this practice no matter what - the thought of multiple backlogs is seen as sacrilege.

If you're creating or maintaining a service based architecture and you have a single backlog, you're setting yourself up for failure. To explain my rationale for this view let me start with a review of the roles of the Product Owner and the prime stakeholder, the originator of the user story (you know the originator as the "AS A" in your well templated Jira stories).

Textbook descriptions of these roles will state that the Product Owner and originator aren't required to be technical. The Product Owner is a skilled negotiator and planner, acting as a proxy for all of the stakeholder and organisational needs. The Product Owner will consider factors including the customer impact of a story, the financial benefit (or detriment), whether unacceptable technical debt will accrue or needs to be tackled. The Product Owner will hear the reasoning for inclusion from the originator of a story and will examine the impact across the scorecard of key metrics - a balanced weighting of what the wider stakeholders require from their product - and will make a prioritisation call on whether a specific story is one that should make the next sprint. The originator of the story, is normally the end-user and will describe a want / need (not a solution!) and from their perspective the focus should be entirely on the shiny end of things and ensuring the Acceptance Criteria are all met when a solution is demonstrated by the development team. Sign-off.

It's worth stating that a good set of ceremonies, when correctly used, will result in a scrum team that is 17% doing agile, 83% being agile. I'll continue with a review of the basics: -

• A story originator can be anyone within the business and the originator simply has a want or need that they believe the development team is required to solve, additionally the Product Owner would like to consider for an upcoming sprint and it is need of refinement.
• Note: The originator is, quite rightly, unlikely to care about your definition of sprint ready, or your Jira templates mandatory fields, or anything else just as formal. They're excited about something and you should embrace this informality, promoting a minimum barrier for entry for innovation and new features from all corners of the operating environment.
• The story only exists in well documented form after it has been refined by the entire scrum team. All relevant stakeholders need to be present (or a good proxy for them) and all Acceptance Criteria should be teased out - no question is too silly, and I can't stress enough that it's 100% not the Product Owners responsibility to get a story in template form and ready for planning, it's the team, together. Honestly it massively boils my piss when a developer drops the excuse "...well you see productivity dropped in the last sprint because the stories weren't rubbish, the Product Owner was on holiday so there was nobody in to sort it out".
• Refinement of the story focuses only on documenting the story originators wants and needs and in a two week sprint I would usually be conducted this during a half-day refinement ceremony at the start of the second week. Here is where all Acceptance Criteria are discovered and everybody should walk away fully understanding the want or need to be solved. If you spot a regular mid-sprint pattern that sees developers quizzing the story originator or other stakeholders, then the refinement wasn't conducted correctly and Acceptance Criteria is likely to have been missed. Productivity will suffer as more often than not corrective work will follow in the next sprint.
• I'd like to slip a couple of 'don't worry' messages in here too. If refinement takes 4 hours and covers only 3 or 4 stories, then I'd say you've had a great refinement session. Trust me, this is perfectly normal, good stories are the result of investment in refinement - you're gonna reap the rewards in the sprint planning and during development of the solution. Additionally, rehearse your response to the initial developer whinging that is guaranteed to be heard "...we just want to be developing, not spending all our time in meetings...". It's a false economy for sure. If developers tracked time spent away from their code working with poor quality stories, they'd be shocked. The fact is they will be developing for 83% of the sprint by investing in the ceremonies correctly. Alternatively, have them clock their wasted time before and after each change to process and give them the options to choose from.
• Finally, be sure to accept that it is the development teams responsibility to create the technical solution to meet the Acceptance Criteria of the story, that is a sign a solution to the want / need has been met. If you review the criteria and assume the team will only code the minimum change to meet the Acceptance Criteria, you'll soon start adding criteria covering Performance, Deployment, Security, Localisation, Architecture, Useability, Reporting, Data Privacy, and so much more - stories with only 1 or 2 Acceptance Criteria* should be printed out and stapled to the members of the refinement session as a reminder of their lack of digging for requirements (please exclude the office dogs).

I have previously posted articles on the composition of a good story and how to identify Acceptance Criteria, also a summary of the well researched topic of the cost of introducing avoidable defects during the story writing phase - if you can't find it, please private message me :-)

So now that we've had a recap of a couple of roles, the responsibilities, and some of the ceremonies involved in a typical scrum based development. I'll now cover off an example to show why a single backlog is a nightmare for larger architectures. Let's take a look at the development of the 2020 Audi Virtual Cockpit and why it is problematic for the non-technical Product Owner and the originator of the original want / need: -

AS A Driver, I WANT a picture of my Audi on the Virtual Cockpit, SO THAT I can remember which side of the car my fuel filler cap is on.

At the very same time you have the 2020 Skoda development backlog (which incorporates the same Virtual Cockpit hardware) and containing a similar story: -

AS A Driver, I WANT a picture of my Skoda on the Virtual Cockpit, SO THAT I can see visually how much petrol is in my vehicle.

Development will then start and both teams tinker with the Virtual Cockpit firmware and implement two completely different mechanisms for representing the vehicle - twice as much storage has been used too - as both teams embedded their own images so hardware costs increase, and software maintenance and servicing costs increase as technical debt is built into the Virtual Cockpit. In the meantime, both Product Owners are happy that Acceptance Criteria have been met and just want to pull the next shiney feature into the upcoming sprint, not a corrective architecture story. This problem is more obvious due to Seat, VW, Audi and Skoda all sharing many identical components that are blatantly the same, than say an e-mail service that has stories hidden amongst end-user website stories that are conflicting.

Options...

Once a development team has become accustomed to spotting products that can exist standalone, or have solution architecture in mind it will be difficult to imagine the need for a specific ceremony or owner for this. However, a good start might be to have a quarterly product identification session with the Scrum Masters and the Solutions Architect and make a conscious effort to search for products that could have the smaller dedicated backlogs, with an appointed member of the development team acting as a now technical Product Owner who will be more suited for spotting conflict and contradiction in what now becomes technical stories fed from their story originator. The smaller backlog is now refined with the two originators from Skoda and Audi and the story can be replaced with a newer agreed one with additional Acceptance Criteria to cover off the spotted configuration need: -

AS A Consumer of the Virtual Cockpit, I WANT a picture of my vehicle on the Virtual Cockpit, SO THAT I can see information about my vehicle.

AC1: The image for the vehicle shall be flashed during assembly

What should now be apparent is that the owner of a technical service is the development team. Or perhaps the developer who created a hypothetical e-mail service. It makes perfect sense because they are most familiar with the service, and originally identified it as being reusable across other products. It will help save on duplicate development, it reduces conflicting requirements being missed and it promotes innovation, whilst giving developers their own 'baby' to look after and be proud of. The e-mail service is certainly not the remit of the Product Owner, who sees his Acceptance Criteria are met for sending e-mails in their top-level story. The Product Owner shouldn't care so much about the architecture (well they should, but you get my point :-).

I should also cover off the counter-argument that I said the development team is responsible for the technical solution so this should be all part of planning and the rough-up-front-design immediately after. In reality, that approach just doesn't work, largely due to practicalities of documenting all considerations and changes to a non-trivial system with multiple services being involved in a any given change.

It's much easier to allow for the creation of downstream stories in the planning sessions for user facing stories, where the backlog is owned by the expert for that service, it can be changed and released as a new version, tested, released and accepted by the story originator before being consumed in the wider change...

If you really do want to change the entire codebase and release multiple components, adding risk and regularly missing architectural patterns and conflicting requirements - then by all means stick to a single backlog with a non-technical Product Owner :-)