Technical architecture hierarchy
We have in the squad, people with different technical skills for the execution of the stories. However, when we look at the technical architecture of the project, we have a division between base APIs, microservices and front end that generates a development hierarchy. It turns out that the development of the base apis often takes time, generates dependency and locks the rest of the layers for development in the last days of the Sprint. Should we break the story into sub stories interspersed between sprints to not generate this dependency? even though the main story wasn't resolved in 1 sprint?
Does the team know why it takes longer to develop the base APIs over the other parts?
Is the team doing just enough design up-front to allow the work to proceed in parallel? Even if you have layers, you can usually do a good enough job to define how the layers or components will communicate to allow a nearly-complete implementation in parallel and then integrate the pieces.
How many people are involved in this? Does the current knowledge or expertise of the team require that different people work on each layer? If so, what are you doing to move from a cross-functional team to cross-functional individuals?
How well separated are the interfaces from the implementation? It seems odd that an API & microservices based architecture has dependencies that are brittle enough to slow the innovation rate.
Tks @Ian Mitchell
Let me step back and elaborate. We are using Scrum and I play a role at this moment as Scrum Master. Suppose the PO brings a story "Change payment method" and during refinement, it is identified by the Tech Lead and team, that to complete this story, we need to change backend, microservices and frontend (3 layers). However, the activities will not start in parallel and the backend will need all of the Sprint to finalize their demands, not giving the microservices and UI team time to finalize their parts and consequently the story/value will not be delivered.
In these cases, how to break the story, since it is not business definition (PO) that will impact and yes, a technical implementation? Considering that a story cannot be longer than the sprint, how do we manage this demand within the sprint?
the activities will not start in parallel and the backend will need all of the Sprint to finalize their demands
In Scrum, the only demand to be finalized is the Definition of Done. What you've described is a stage gate indicative of a waterfall process. A Sprint ought to be a collaborative learning experiment.
In your example, why can't the work start in parallel? The team can (and should) be using refinement to do just enough up-front design to enable all of the work to start. The kind of work that can be done in refinement would include defining the data and any data migrations, interfaces between components, user interface design, and any other work. You may have to acknowledge that, as you do the work, you encounter something that you didn't think of, but you've at least done enough to start the three teams able to start and increase the chances of delivery of a valuable change within the Sprint timebox.
Hi @Ian Mitchell and @Thomas Owens
I understand your points. I can't try to organize the sequence of dependent stories, I have to figure out how to run all three at the same time, using refinement for that and delivering the committed value in the Sprint.
Change the mindset, so as not to run a waterfall within agile.
Thanks