You’re welcome Nicole.

Hi Clement, Thanks for sharing your questions. You can find my advice on applying the business analyst role in Scrum in the article Business Analysts in Scrum. How you best manage requirements will depend on the process you use. If you apply Scrum, then you may want to read my articles 5 Tips for Stocking the Product Backlog and The Product Backlog Refinement Steps. Hope this helps!

Thanks for sharing your feedback and question Sim. If you want to capture how end users will use the ERP functionality, then user stories should be well suited. Bear in mind, though, that a story does not specify a requirement–at least not on its own. It has to be complemented by a conversation. Understanding the users’ needs and creating personas can help you discover the right user stories, as I mention in the article. Additionally, you will benefit from working with a validated product strategy and an actionable product roadmap. Hope this helps!

A couple of questions around user stories that you might be able to help me with:
1. I am trying to make use of user stories in the context of an ERP system selection, i.e., not a development, but the acquisition of an existing system. These systems can be configured, but we are trying to avoid the cost and lock-in of customising vendor code to bend these systems to do things in ways that are not part of the systems out of the box. Do you think it practical to specify requirements based on User Stories in this way for a selection exercise?
2. How should we handle ‘overshoot’ with the user stories (either in a selection or a development)? How do we ensure the user stories aren’t asking for a Ferrari when a Fiat meets the needs of the business?

Thanks,
Sim Teo

Thanks for your feedback and questions Nermin. Regarding a timeline for grooming/refinement, please take a look at my article “When Should Porduct backlog Refinement Take Place?” I am afraid I can’t answer your questions two and three, as I am not a SAFe expert. I suggest that you refer to the SAFe documentation. Hope this helps!

Hence when we groom stories for a scaled agile release, then the stories should be estimated and groomed before planning day of the release. However I see many coaches advising to enter planning day without predefined stories. Eventually we end up with delayed testing, for weeks, as team is still refining the stories during the sprints.

– Can you advise about the realistic timeline to start defining the stories and it’s according acceptance criteria?
– Do you agree that entering a scaled release planning day with predefined stories is a Product Owner sin of pride?
– What do you advise product owners who recently switched from scrum to scaled agile releases and have to prepare for planning day?

Thanks in advance.

Thanks for sharing your feedback and question Siddarth. By definition, user stories describe end user requirements. You can, of course, tell stories about how a product is built using technical stories. But I find that natural language is not well suited to capture technical requirements, and I prefer to work with a modelling language like UML (Unified Modeling Language). If you manage a technical product like a software platform, you should have the necessary technical knowledge to capture the requirements for this product. Hope this answer is helpful.

Thanks for sharing your question Jaya. The activities you mentioned should be covered by the Definition of Done and they may result in tasks captured on the sprint backlog, assuming the development teams uses capacity-driven sprint planning. Hope this helps!