In traditional software development, a business analyst is responsible for gathering the users’ requirements, translating them into other formats like requirement specifications or user stories, and requesting the developers to commence the development work.
When a team adopts Scrum, they often feel unsure of where to start. In most cases, the business analyst will assume the role of the Product Owner. This decision is based on the intuitive similarity between the responsibilities of a business analyst and those of a Product Owner.
I am a developer. I don’t write user stories. It’s the Product Owner’s job.
If the Product Backlog Item isn’t written clearly, I won’t start working on it.
I only write technical stories.
I often hear from the team who is new to Scrum.
During the initial phase, our team has just learned about microservice development. Most of the developers laced proficiency in this technique. As a Product Owner with a technical background, I decided to incorporate all the interactions in the Product Backlog Items as the acceptance criteria. For instance:
Given a XXXEvent from Microservice A with MMM context,
When Microservice B receives the XXXEvent,
Then MIcroservice B should call KKK RESTful API from Microservice C, and create a YYYEvent and send it to Microservice D.
The developers felt happy and at ease. They only followed the acceptance criteria and implemented the technical details. Through months of practice, they learned about the microservice architecture design by working on these well-prepared Product Backlog Items.
As the business and the interactions between the microservices have become more complex, it’s infeasible for me to include all the low-level details in the Product Backlog Items nowadays.
A frustrated Product Owner endlessly writing backlog items
Fortunately, not just the product is growing, but the developers who joined in the early stage are growing too. I want to empower the developers to make decisions regarding the technical details, including the “what” and “how”. Meanwhile, I focus more on the business context and roughly mention the microservices involved. I intentionally leave spaces in the technical details of the Product Backlog Items.
“This PBI lacks the technical details of the event-driven design,” a less experienced developer asked, “And how should I handle the null in that method?”
“I don’t know,” I replied, “Go and explore yourself, and write down your findings in the PBI. I can only provide the Product Goal, the reason behind this PBI, and the important points to consider.”
Initially, the developer felt weird and uncomfortable. They suffered a bit in Cycle Time as they invested time in exploration and encountering potential pitfalls. However, after a few weeks, they started to adapt to the new way of work. They began to grasp the purpose behind the Product Backlog Items. They deep-dived the product, addressed the business and technical details, and supplemented the details or split the Product Backlog Items when necessary.
I want the developers to escape from the Feature Factory, and join me in becoming a cohesive unit of professionals focused on the Product Goal.
Of course, I remain accountable to the Product Backlog. After I delegate the responsibility to the developers, I free up more time to explore other areas, particularly those outside the Sprint. This allows me to focus on the work such as formulating the Product Roadmap and working with stakeholders.
Think about it. If I had continued to include all the details in the PBIs, I would have been overwhelmed and unable to prepare all the PBIs before the start of a new Sprint. The developers would have remained stuck in the Feature Factory, waiting for the PBIs to be handed to them. This would not motivate them to understand the product. Without a clear goal beyond merely completing all the PBIs, they would lack a sense of belonging. Instead of functioning as a cohesive team, they would be a group of individuals working in isolation.