How can you handle user stories that require significant technical effort?

All of these user stories which require high technical effort should be written along with the dev. This also takes care of breaking them into smaller segments. Once we sit with dev and let them explain to us how exactly the tech would work in a given scenario, writing such user stories becomes easier.

One basic thumb rule is to not only ensure user story is small enough to be done in a sprint but also ensure there is only one tangible output from it. If a user story has strong technical dependencies, one way is to identify the dependencies as separate user story and make them dependent.

In my experience, two signs indicating a probable need for breaking user stories into smaller ones are: 1. Large estimations that do not fit within a sprint. 2. Inability to estimate it at all, which could be due to various reasons, such as significant technical effort or other factors.

First there should be an - architectural design and review story ( which needs to be reviewed in collaboration architecture team, devops team and engg team) - POC tasks, where each scrum team can do their indivisual POC. - Post POC, each module can be divided into stories ( large stories can be broken down in sub stories) - Priority order of delivery and integration of the stories has to be decided in collaboration of different engg team ( which activity has to be done after which) - Based on this Stories have to added in release vehicles for each component and then devops team will be informed All this can be done in collaboration with Program managers who oversees delivery and ensures the syncronization -

Backlog grooming ritual needs to be planned at least one sprint ahead. This includes running through the upcoming user stories with technical team, breaking it down to be minimalistic to realise within a sprint, identify technical dependencies, creating dependent user stories, identifying risks and mitigation actions.

2 things have worked for me here: - Involving them from the start itself. - Avoiding the handoff culture. The former ensures that the direction is undertaken as per the existing infra and constraints that we have. Later ensures there is enough room for devs to get back to us in case of any issues which might arrive on the go.

Communicating the value behind an effort taking task can do wonders here: It is best if the devs are kept looped in to see the impact themselves since it is their hardcore effort involved.

Technical user stories may not deliver value for customers but definitely is needed as it can be platform for delivering value. From customer point of view, it becomes necessary for PM to balance the deliverables i.e. calls for prioritisation in such a way that every release has some minimum value delivered.

Defining acceptance criteria appropriately is very important for a user story. This should be discussed and agreed with development team as well. Acceptance criteria provides vital inputs for validation as well.

Another helpful practice involves conducting an Internal Validation at the conclusion of each iteration. During this process, the development team presents the working product to the Product Owner and other stakeholders to ensure alignment with the user story and acceptance criteria. This event, commonly known as the Sprint Review meeting, offers several benefits: 1. Encourages the development team to deliver working software by the end of each iteration. 2. Facilitates valuable feedback from stakeholders. 3. Allows the Product Owner to approve whether the work aligns with the User Story and Acceptance Criteria.

Technical debt user stories also needs to be captured involving development team which needs to be prioritised appropriately in the backlog. Technical debts are to be resolved at the earliest to ensure good quality products, however may not provide tangible value to customer so calks for appropriate prioritisation and inclusion in every sprint