Skip to main content

Technical architecture hierarchy

Last post 02:16 pm July 21, 2023 by DANIEL GODOY
6 replies
10:47 am July 15, 2023

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?


10:24 pm July 16, 2023

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?


02:07 am July 17, 2023

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.


06:02 pm July 19, 2023

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?


12:53 am July 20, 2023

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.


12:52 pm July 20, 2023

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.


02:16 pm July 21, 2023

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


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.