Where is the right place for software architecture discussions in Scrum?
"Where is the right place for software architecture discussions in Scrum? Maybe in a backlog refinement meeting?"...
Andreas: Certain architectural requirements are non-functional requirements that are attached to the whole product backlog as constraints (restrictions or conditions), to some extent as part of the product vision, or they are acceptance criteria and tests for each product backlog item. If to fulfill these constraints or acceptance criteria any tasks need to be done, these are added to the sprint backlog together with all the other tasks. I would restrict the technical clarifications during backlog refinement meetings to the information and feedback necessary to estimate the story and to the clarification of the acceptance criteria.
Peter: The acceptance criteria for the constraints are in the definition of done. Each sprint the team must demonstrate that a constraint is satisfied. Architecture means that a team can satisfy a constraint permanently. In practice I was able to help teams build the architecture mapping constraints to technically verifiable criteria which had to be met initally. Those were added to the backlog and prioritized by risk. For example, the constraint "scalability" can be implemented with the backlog item "demonstrate scalability and ensure it for the further development". In this case the DoD would contain in the future: "For every sprint result scalability was proved by load tests." In this way the team forces itself to build the infrastructure, to make fundamental decisions about the architecture and to develop them incrementally in the right direction.
By the way constraints must always be prioritized by the PO as they have values and mean costs. What availability rate should the produt have so that the users were satisfied? How much does it cost?
About the author
Andreas Schliep
Andreas Schliep is a founding member and executive partner of DasScrumTeam. He is a Scrum coach and trainer. He studied at the technical university of Bremerhaven, and worked as a software developer, project manager, team lead and group lead. Andreas has worked with Scrum since 2003. He became a full-time Scrummer in 2006.
Since then, he has helped to introduce and improve Scrum and agile practices in numerous companies all over the world. His favorite topics are quality management and scaling.
- Experienced ScrumMaster, Product Owner, Coach and Trainer
- Introduced Scrum at WEB.DE
- Coaching of internationally distributed teams
- Transition from RUP to Scrum at UOL Brazil
- Scrum Trainings and Coaching in Germany, Switzerland and Austria
About the author
Peter Beck
Peter has set himself the task of creating companies that deliver value for their customers and employees. That was also the motivation behind his decision to found DasScrumTeam. Peter is a passionate Scrum Trainer (Certified Scrum Trainer, CST) and consultant with a solid background in engineering. Since 2007, he has trained and advised a wide range of development teams, specialist departments, project managers and those in leadership positions, helping them to apply the Scrum framework, agile planning methods and software engineering practices. Peter is a graduate engineer (Dipl.-Ing, TU) specialising in electrical engineering and information technology.
- Experience with Scrum since 2004 as Team member, Scrum Master, Product Owner, Coach and Trainer.
- Served as ScrumMaster in internationally distributed Scrum Teams
- Co-founder and Product Owner at DasScrumTeam AG
- Key interests: Agile companies and Scrum beyond Software
Always up to date with the DasScrumTeam newsletter.
The best in terms of Scrum. Once a month. Every month.