fix links

docs/ENG-FUNDAMENTALS-CHECKLIST.md

@@ -69,7 +69,7 @@ More details on [agile development](agile-development/README.md)
 
 ## Design Reviews
 
-- [ ] Process for conducting design reviews is included in the [Working Agreement](agile-development/advanced-topics/team-agreements/working-agreements.md).
+- [ ] Process for conducting design reviews is included in the [Working Agreement](agile-development/team-agreements/working-agreements.md).
 - [ ] Design reviews for each major component of the solution are carried out and documented, including alternatives.
 - [ ] Stories and/or PRs link to the design document.
 - [ ] Each user story includes a task for design review by default, which is assigned or removed during sprint planning.
@@ -97,7 +97,7 @@ More details on [code reviews](code-reviews/README.md)
 - [ ] Experiments have owners and are added to project backlog.
 - [ ] The team conducts longer retrospective for Milestones and project completion.
 
-More details on [retrospectives](agile-development/basics/ceremonies.md#retrospectives)
+More details on [retrospectives](agile-development/ceremonies.md#retrospectives)
 
 ## Engineering Feedback
 

docs/SPRINT-STRUCTURE.md

@@ -11,10 +11,10 @@ The purpose of this document is to:
 ### Before starting the project
 
 - [ ] Discuss and start writing the Team Agreements. Update these documents with any process decisions made throughout the project
-  - [Working Agreement](agile-development/advanced-topics/team-agreements/working-agreements.md)
-  - [Definition of Ready](agile-development/advanced-topics/team-agreements/definition-of-ready.md)
-  - [Definition of Done](agile-development/advanced-topics/team-agreements/definition-of-done.md)
-  - [Estimation](agile-development/basics/ceremonies.md#estimation)
+  - [Working Agreement](agile-development/team-agreements/working-agreements.md)
+  - [Definition of Ready](agile-development/team-agreements/definition-of-ready.md)
+  - [Definition of Done](agile-development/team-agreements/definition-of-done.md)
+  - [Estimation](agile-development/ceremonies.md#estimation)
 - [ ] [Set up the repository/repositories](source-control/README.md#creating-a-new-repository)
   - Decide on repository structure/s
   - Add [README.md](resources/templates/README.md), [LICENSE](resources/templates/LICENSE), [CONTRIBUTING.md](resources/templates/CONTRIBUTING.md), .gitignore, etc
@@ -25,7 +25,7 @@ The purpose of this document is to:
 
 ### Day 1
 
-- [ ] [Plan the first sprint](agile-development/basics/ceremonies.md#sprint-planning)
+- [ ] [Plan the first sprint](agile-development/ceremonies.md#sprint-planning)
   - Agree on a sprint goal, and how to measure the sprint progress
   - Determine team capacity
   - Assign user stories to the sprint and split user stories into tasks
@@ -42,15 +42,15 @@ The purpose of this document is to:
 - [ ] [Set up Source Control](source-control/README.md)
   - Agree on [best practices for commits](source-control/git-guidance/README.md#commit-best-practices)
 - [ ] [Set up basic Continuous Integration with linters and automated tests](continuous-integration/README.md)
-- [ ] [Set up meetings for Daily Stand-ups and decide on a Process Lead](agile-development/basics/ceremonies.md#stand-up)
+- [ ] [Set up meetings for Daily Stand-ups and decide on a Process Lead](agile-development/ceremonies.md#stand-up)
   - Discuss purpose, goals, participants and facilitation guidance
   - Discuss timing, and how to run an efficient stand-up
 - [ ] [If the project has sub-teams, set up a Scrum of Scrums](agile-development/advanced-topics/effective-organization/scrum-of-scrums.md)
 
 ### Day 3
 
 - [ ] [Agree on code style](code-reviews/README.md) and on [how to assign Pull Requests](code-reviews/pull-requests.md)
-- [ ] [Set up Build Validation for Pull Requests (2 reviewers, linters, automated tests)](code-reviews/README.md) and agree on [Definition of Done](agile-development/advanced-topics/team-agreements/definition-of-done.md)
+- [ ] [Set up Build Validation for Pull Requests (2 reviewers, linters, automated tests)](code-reviews/README.md) and agree on [Definition of Done](agile-development/team-agreements/definition-of-done.md)
 - [ ] [Agree on a Code Merging strategy](source-control/merge-strategies.md) and update the [CONTRIBUTING.md](resources/templates/CONTRIBUTING.md)
 - [ ] [Agree on logging and observability frameworks and strategies](observability/README.md)
 
@@ -64,12 +64,12 @@ The purpose of this document is to:
 
 ### Day 5
 
-- [ ] Conduct a [Sprint Demo](agile-development/basics/ceremonies.md#sprint-demo)
-- [ ] Conduct a [Retrospective](agile-development/basics/ceremonies.md#retrospectives)
+- [ ] Conduct a [Sprint Demo](agile-development/ceremonies.md#sprint-demo)
+- [ ] Conduct a [Retrospective](agile-development/ceremonies.md#retrospectives)
   - Determine required participants, how to capture input (tools) and outcome
   - Set a timeline, and discuss facilitation, meeting structure etc.
 - [ ] [Refine the Backlog](agile-development/advanced-topics/backlog-management)
   - Determine required participants
-  - Update the [Definition of Ready](agile-development/advanced-topics/team-agreements/definition-of-ready.md)
-  - Update estimates, and the [Estimation](agile-development/basics/ceremonies.md#estimation) document
+  - Update the [Definition of Ready](agile-development/team-agreements/definition-of-ready.md)
+  - Update estimates, and the [Estimation](agile-development/ceremonies.md#estimation) document
 - [ ] [Submit Engineering Feedback for issues encountered](engineering-feedback/README.md)

docs/agile-development/advanced-topics/effective-organization/scrum-of-scrums.md

@@ -1,6 +1,6 @@
 # Scrum of Scrums
 
-Scrum of scrums is a technique used to scale Scrum to a larger group working towards the same project goal. In Scrum, we consider a team being too big when going over 10-12 individuals. This should be decided on a case by case basis. If the project is set up in multiple work streams that contain a fixed group of people and a common [stand-up](../../basics/ceremonies.md#stand-up) meeting is slowing down productivity: scrum of scrums should be considered. The team would identify the different subgroups that would act as a separate scrum teams with their own backlog, board and stand-up.
+Scrum of scrums is a technique used to scale Scrum to a larger group working towards the same project goal. In Scrum, we consider a team being too big when going over 10-12 individuals. This should be decided on a case by case basis. If the project is set up in multiple work streams that contain a fixed group of people and a common [stand-up](../../ceremonies.md#stand-up) meeting is slowing down productivity: scrum of scrums should be considered. The team would identify the different subgroups that would act as a separate scrum teams with their own backlog, board and stand-up.
 
 ## Goals
 
@@ -15,7 +15,7 @@ The scrum of scrums ceremony happens every day and can be seen as a regular stan
 
 The outcome of the meeting will result in a list of impediments related to coordination of the whole project. Solutions could be: agreeing on interfaces between teams, discussing architecture changes, evolving responsibility boundaries, etc.
 
-This list of impediments is usually managed in a separate [backlog](../../basics/backlog-management.md) but does not have to.
+This list of impediments is usually managed in a separate [backlog](../../backlog-management.md) but does not have to.
 
 ## Participation
 
@@ -29,7 +29,7 @@ When choosing to implement Scrum of Scrums, you need to keep in mind that some t
 
 ## Measures
 
-The easiest way to measure the impact is by tracking the time to resolve issues in the scrum of scrums backlog. You can also track issues reported during the [retrospective](../../basics/ceremonies.md#retrospectives) related to global coordination (is it well done? can it be improved?).
+The easiest way to measure the impact is by tracking the time to resolve issues in the scrum of scrums backlog. You can also track issues reported during the [retrospective](../../ceremonies.md#retrospectives) related to global coordination (is it well done? can it be improved?).
 
 ## Facilitation Guidance
 

docs/design/design-reviews/recipes/engagement-process.md

@@ -21,7 +21,7 @@ During this time the team uncovers many unknowns, leveraging all new-found infor
 
 ## Sprint Planning
 
-In many engagements Microsoft works with customers using a SCRUM agile development process which begins with sprint planning. [Sprint planning](../../../agile-development/basics/ceremonies.md#sprint-planning) is a great opportunity to dive deep into the next set of high priority work. Some key points to address are the following:
+In many engagements Microsoft works with customers using a SCRUM agile development process which begins with sprint planning. [Sprint planning](../../../agile-development/ceremonies.md#sprint-planning) is a great opportunity to dive deep into the next set of high priority work. Some key points to address are the following:
 
 1. Identify stories that require design reviews
 1. Separate design from implementation for complex stories
@@ -48,7 +48,7 @@ The team can follow the same steps from [sprint planning](#sprint-planning) to h
 
 ## Sprint Retrospectives
 
-[Sprint retrospectives](../../../agile-development/basics/ceremonies.md#retrospectives) are a great time to check in with the dev team, identify what is working or not working, and propose changes to keep improving.
+[Sprint retrospectives](../../../agile-development/ceremonies.md#retrospectives) are a great time to check in with the dev team, identify what is working or not working, and propose changes to keep improving.
 
 It is also a great time to check in on design reviews
 
@@ -58,7 +58,7 @@ It is also a great time to check in on design reviews
 
 All design artifacts should be treated as a living document. As requirements change or uncover more unknowns the dev crew should retroactively update all design artifacts. Missing this critical step may cause the customer to incur future technical debt. Artifacts that are not up to date are `bugs` in the design.
 
-> **Tip:** Keep your artifacts up to date by adding it to your teams [Definition of Done](../../../agile-development/advanced-topics/team-agreements/definition-of-done.md) for all user stories.
+> **Tip:** Keep your artifacts up to date by adding it to your teams [Definition of Done](../../../agile-development/team-agreements/definition-of-done.md) for all user stories.
 
 ## Sync Design Reviews
 

docs/design/design-reviews/recipes/engineering-feasibility-spikes.md

@@ -89,4 +89,4 @@ Conducting engineering feasibility spikes sets the team and the customer up for
 - The key purpose of the engineering feasibility spike is learning.
 - Learning comes from both conducting and sharing insights from spikes.
 - Use new spike infused learnings to revise, refine, re-prioritize, or create the next set of spikes.
-- When spikes are completed, look for new weekly rhythms like adding a ‘risk’ column to the retro board or raising topics at [daily standup](../../../agile-development/basics/ceremonies.md#stand-up) to identify emerging risks.
+- When spikes are completed, look for new weekly rhythms like adding a ‘risk’ column to the retro board or raising topics at [daily standup](../../../agile-development/ceremonies.md#stand-up) to identify emerging risks.

docs/design/design-reviews/recipes/high-level-design-recipe.md

@@ -6,7 +6,7 @@ Design at macroscopic level shows the interactions between systems and services
 
 ## Things to keep in mind
 
-* As with all other aspects of the project, design reviews must provide a friendly and safe environment so that any team member feels comfortable proposing a design for review and can use the opportunity to grow and learn from the constructive / non-judgemental feedback from peers and subject-matter experts (see [Team Agreements](../../../agile-development/advanced-topics/team-agreements/README.md)).
+* As with all other aspects of the project, design reviews must provide a friendly and safe environment so that any team member feels comfortable proposing a design for review and can use the opportunity to grow and learn from the constructive / non-judgemental feedback from peers and subject-matter experts (see [Team Agreements](../../../agile-development/team-agreements/README.md)).
 * Attempt to illustrate different personas involved in the use cases and how/which boxes are their entry points.
 * Prefer pictures over paragraphs. The diagrams aren't intended to generate code, so they should be fairly high level.
   * Artifacts should indicate the direction of calls (are they outbound, inbound, or bidirectional?) and call out system boundaries where ports might need to be opened or additional infrastructure work may be needed to allow calls to be made.

docs/design/design-reviews/recipes/milestone-epic-design-review-recipe.md

@@ -6,7 +6,7 @@ Design at epic/milestone level can help the team make better decisions about pri
 
 ## Things to keep in mind
 
-* As with all other aspects of the project, design reviews must provide a friendly and safe environment so that any team member feels comfortable proposing a design for review and can use the opportunity to grow and learn from the constructive / non-judgemental feedback from peers and subject-matter experts (see [Team Agreements](../../../agile-development/advanced-topics/team-agreements)).
+* As with all other aspects of the project, design reviews must provide a friendly and safe environment so that any team member feels comfortable proposing a design for review and can use the opportunity to grow and learn from the constructive / non-judgemental feedback from peers and subject-matter experts (see [Team Agreements](../../../agile-development/team-agreements)).
 * Design reviews should be lightweight and should not feel like an additional process overhead.
 * Dev Lead can usually provide guidance on whether a given epic/milestone needs a design review and can help other team members in preparation.
 * This is *not* a strict template that must be followed and teams should not be bogged down with polished "design presentations".

docs/design/design-reviews/recipes/templates/feature-story-design-review.md

@@ -20,7 +20,7 @@
 ## Goals/In-Scope
 
 * List the goals that the feature/story will help us achieve that are most relevant for the design review discussion.
-* This should include acceptance criteria required to meet [definition of done](../../../../agile-development/advanced-topics/team-agreements/definition-of-done.md).
+* This should include acceptance criteria required to meet [definition of done](../../../../agile-development/team-agreements/definition-of-done.md).
 
 ## Non-goals / Out-of-Scope
 

docs/design/design-reviews/recipes/templates/milestone-epic-design-review.md

@@ -14,7 +14,7 @@
 
 ## Goals / In-Scope
 
-> List a few bullet points of goals that this milestone/epic will achieve and that are most relevant for the design review discussion. You may include acceptable criteria required to meet the [Definition of Done](../../../../agile-development/advanced-topics/team-agreements/definition-of-done.md).
+> List a few bullet points of goals that this milestone/epic will achieve and that are most relevant for the design review discussion. You may include acceptable criteria required to meet the [Definition of Done](../../../../agile-development/team-agreements/definition-of-done.md).
 
 ## Non-goals / Out-of-Scope
 

docs/design/design-reviews/recipes/templates/template-task-design-review.md

@@ -21,7 +21,7 @@
 ## Goals/In-Scope
 
 * List a few bullet points of what this task will achieve and that are most relevant for the design review discussion.
-* This should include acceptance criteria required to meet the [definition of done](../../../../agile-development/advanced-topics/team-agreements/definition-of-done.md).
+* This should include acceptance criteria required to meet the [definition of done](../../../../agile-development/team-agreements/definition-of-done.md).
 
 ## Non-goals / Out-of-Scope
 
@@ -30,8 +30,8 @@
 ## Proposed Options
 
 * Describe the detailed design to accomplish the proposed task.
-* What patterns & practices will be used and why were they chosen.  
-* Were any alternate proposals considered?  
+* What patterns & practices will be used and why were they chosen.
+* Were any alternate proposals considered?
 * What new components are required to be developed?
 * Are there any existing components that require updates?
 * Relevant diagrams (e.g. sequence, component, context, deployment) should be included here.

docs/developer-experience/onboarding-guide-template.md

@@ -16,7 +16,7 @@ When developing an onboarding document for a team, it should contain details of
 ## Team Agreement and Code of Conduct
 
 * Include the team's code of conduct or agreement that defines a set of expectation from each team member and how the team has agreed to operate.
-* Working Agreement Template - [working agreement](../agile-development/advanced-topics/team-agreements/working-agreements.md)
+* Working Agreement Template - [working agreement](../agile-development/team-agreements/working-agreements.md)
 
 ## Dev Environment Setup
 

docs/documentation/guidance/project-and-repositories.md

@@ -31,16 +31,16 @@ Some sections in the documentation of the repository might point to the project
 - [Onboarding](../../developer-experience/onboarding-guide-template.md)
 - Repository guide
   - Production, Spikes
-- [Team agreements](../../agile-development/advanced-topics/team-agreements/README.md)
-  - [Team Manifesto](../../agile-development/advanced-topics/team-agreements/team-manifesto.md)
+- [Team agreements](../../agile-development/team-agreements/README.md)
+  - [Team Manifesto](../../agile-development/team-agreements/team-manifesto.md)
     - Short summary of expectations around the technical way of working and supported mindset in the team.
     - E.g., ownership, respect, collaboration, transparency.
-  - [Working Agreement](../../agile-development/advanced-topics/team-agreements/working-agreements.md)
+  - [Working Agreement](../../agile-development/team-agreements/working-agreements.md)
     - How we work together as a team and what our expectations and principles are.
     - E.g., communication, work-life balance, scrum rhythm, backlog management, code management.
-  - [Definition of Done](../../agile-development/advanced-topics/team-agreements/definition-of-done.md)
+  - [Definition of Done](../../agile-development/team-agreements/definition-of-done.md)
     - List of tasks that must be completed to close a user story, a sprint, or a milestone.
-  - [Definition of Ready](../../agile-development/advanced-topics/team-agreements/definition-of-ready.md)
+  - [Definition of Ready](../../agile-development/team-agreements/definition-of-ready.md)
     - How complete a user story should be in order to be selected as candidate for estimation in the sprint planning.
 - Contributing Guide
   - Repo structure

docs/machine-learning/ml-project-management.md

@@ -14,17 +14,17 @@ To learn more about how ISE runs the Agile process for software development team
 Within this framework, the team follows these Agile ceremonies:
 
 - [Backlog management](../agile-development/advanced-topics/backlog-management)
-- [Retrospectives](../agile-development/basics/ceremonies.md#retrospectives)
+- [Retrospectives](../agile-development/ceremonies.md#retrospectives)
 - [Scrum of Scrums](../agile-development/advanced-topics/effective-organization/scrum-of-scrums.md) (where applicable)
-- [Sprint planning](../agile-development/basics/ceremonies.md#sprint-planning)
-- [Stand-ups](../agile-development/basics/ceremonies.md#stand-up)
-- [Working agreement](../agile-development/advanced-topics/team-agreements/working-agreements.md)
+- [Sprint planning](../agile-development/ceremonies.md#sprint-planning)
+- [Stand-ups](../agile-development/ceremonies.md#stand-up)
+- [Working agreement](../agile-development/team-agreements/working-agreements.md)
 
 ### Notes on Agile process during exploration and experimentation
 
 1. While acknowledging the fact that ML user stories and research spikes are less predictable than software development ones, we strive to have a deliverable for every user story in every sprint.
 
-2. User stories and spikes are usually estimated using [T-shirt sizes](../agile-development/basics/ceremonies.md#estimation) or similar, and not in actual days/hours.
+2. User stories and spikes are usually estimated using [T-shirt sizes](../agile-development/ceremonies.md#estimation) or similar, and not in actual days/hours.
 
 3. ML design sessions should be included in each sprint.