more agile cleanup, fix wording, reduce depth in lists etc.

docs/agile-development/advanced-topics/backlog-management/minimal-slices.md

@@ -3,7 +3,6 @@
 ## Always deliver your work using minimal valuable slices
 
 - Split your work item into small chunks that are contributed in incremental commits.
-
 - Contribute your chunks frequently. Follow an iterative approach by regularly providing updates and changes to the team. This allows for instant feedback and early issue discovery and ensures you are developing in the right direction, both technically and functionally.
 
 - Do NOT work independently on your task without providing any updates to your team.

docs/agile-development/advanced-topics/collaboration/add-pairing-field-azure-devops-cards.md

@@ -4,7 +4,7 @@ This document outlines the benefits of adding a custom field of type _Identity_
 
 ## Benefits of adding a custom field
 
-Having the names of both individuals [pairing on a story](README.md) visible on the Azure DevOps cards can be helpful during sprint ceremonies and lead to greater accountability by the pairing assignee. For example, it is easier to keep track of the individuals assigned stories as part of a pair during sprint planning by using the "pairing names" field. During stand-up it can also help the Process Lead filter stories assigned to the individual (both as an owner or as a pairing assignee) and show these on the board. Furthermore, the pairing field can provide an additional data point for reports and burndown rates.
+Having the names of both individuals pairing on a story visible on the Azure DevOps cards can be helpful during sprint ceremonies and lead to greater accountability by the pairing assignee. For example, it is easier to keep track of the individuals assigned stories as part of a pair during sprint planning by using the "pairing names" field. During stand-up it can also help the Process Lead filter stories assigned to the individual (both as an owner or as a pairing assignee) and show these on the board. Furthermore, the pairing field can provide an additional data point for reports and burndown rates.
 
 ## Prerequisites
 

docs/agile-development/advanced-topics/collaboration/pair-programming-tools.md

@@ -1,6 +1,6 @@
 # Effortless Pair Programming with GitHub Codespaces and VSCode
 
-Pair programming used to be a software development technique in which two programmers work together on a single computer, sharing one keyboard and mouse, to jointly design, code, test, and debug software. It is one of the patterns explored in the section [why collaboration?](./why-collaboration.md) of this playbook, however with teams that work mostly remotely, sharing a physical computer became a challenge, but opened the door to a more efficient approach of pair programming.
+Pair programming used to be a software development technique in which two programmers work together on a single computer, sharing one keyboard and mouse, to jointly design, code, test, and debug software. It is one of the patterns explored in the section [why collaboration?](why-collaboration.md) of this playbook, however with teams that work mostly remotely, sharing a physical computer became a challenge, but opened the door to a more efficient approach of pair programming.
 
 Through the effective utilization of a range of tools and techniques, we have successfully implemented both pair and swarm programming methodologies. As such, we are eager to share some of the valuable insights and knowledge gained from this experience.
 

docs/agile-development/advanced-topics/collaboration/teaming-up.md

@@ -12,7 +12,7 @@ However those phases can be extremely fast or sometimes mismatched in teams due
 In order to minimize the risk and set the expectations on the right way for all parties, an identification phase is important to understand each other.
 Some potential steps in this phase may be as following (not limited):
 
-- [Working agreement](../team-agreements/working-agreements.md)
+- [Working agreement](../../team-agreements/working-agreements.md)
 
 - Identification of styles/preferences in communication, sharing, learning, decision making of each team member
 
@@ -29,7 +29,7 @@ Some potential steps in this phase may be as following (not limited):
 
 - Identification of communication channels, feedback loops and recurrent team call slots out of regular sprint meetings
 
-- Introduction to [Technical Agility Team Manifesto](../team-agreements/team-manifesto.md) and planning the technical delivery by aiming to keep
+- Introduction to [Technical Agility Team Manifesto](../../team-agreements/team-manifesto.md) and planning the technical delivery by aiming to keep
 technical debt risk minimum.
 
 ## Following the Plan and Agile Debugging
@@ -50,7 +50,7 @@ Just as an example, agility debugging activities may include:
   - Are Acceptance Criteria enough and right?
   - Is everyone ready-to-go after taking the User Story/Task?
 
-- Running [Efficient Retrospectives](../../basics/ceremonies.md#retrospectives)
+- Running [Efficient Retrospectives](../../ceremonies.md#retrospectives)
 
 - Is the Sprint Goal clear in every iteration ?
 

docs/agile-development/advanced-topics/effective-organization/delivery-plan.md

@@ -19,20 +19,20 @@ Delivery Plans ensure your teams are aligning with your organizational goals.
 
 One approach you can take to accomplish is with stickies and a spreadsheet.
 
-Step 1: Stack rank the features for everything in your backlog
+1. Stack rank the features for everything in your backlog
 
-- Functional Features
-- [Non-functional Features] (docs/non-functional-requirements)
-- User Research and Design
-- Testing
-- Documentation
-- Knowledge Transfer/Support Processes
+    - Functional Features
+    - [Non-functional Features](../../../non-functional-requirements/)
+    - User Research and Design
+    - Testing
+    - Documentation
+    - Knowledge Transfer/Support Processes
 
-Step 2: T-Shirt Features in terms of working weeks per person. In some scenarios, you have no idea how complex the work. In this situation, you can ask for time to conduct a spike (timebox the effort so you can get back on time).
+1. T-Shirt Features in terms of working weeks per person. In some scenarios, you have no idea how complex the work. In this situation, you can ask for time to conduct a spike (timebox the effort so you can get back on time).
 
-Step 3: Calculate the capacity for the team based on the number of weeks person with his/her start and end date and minus holidays, vacation, conferences, training, and onboarding days. Also, minus time if the person is also working on defects and support.
+1. Calculate the capacity for the team based on the number of weeks person with his/her start and end date and minus holidays, vacation, conferences, training, and onboarding days. Also, minus time if the person is also working on defects and support.
 
-Step 4: Based on your capacity, you know have the options
+Based on your capacity, you know have the options
 
 - Ask for more resources. Caution: onboarding new resources take time.
 - Reduce the scope to the most MVP.  Caution: as you trim more of the scope, it might not be valuable anymore to the customer. Consider a cupcake which is everything you need. You don't want to skim off the frosting.

docs/agile-development/basics/backlog-management.md → docs/agile-development/backlog-management.md

@@ -2,17 +2,19 @@
 
 ## Backlog
 
+**Goals**
+
 - User stories have a clear acceptance criteria and definition of done.
 - Design activities are planned as part of the backlog (a design for a story that needs it should be done before it is added in a Sprint).
 
 **Suggestions**
 
 - Consider the backlog refinement as an ongoing activity, that expands outside of the typical "Refinement meeting".
+- The team should decide on and have a clear understanding of a [definition of ready](team-agreements/definition-of-ready.md) and a [definition of done](team-agreements/definition-of-done.md).
+- The team should have a clear understanding of what constitutes good acceptance criteria for a story/task, and decide on how stories/tasks are handled. Eg. in some projects, stories are refined as a crew, but tasks are created by individual developers on an as needed bases.
 - Technical debt is mostly due to shortcuts made in the implementation as well as the future maintenance cost as the natural result of continuous improvement. Shortcuts should generally be avoided. In some rare instances where they happen, prioritizing and planning improvement activities to reduce this debt at a later time is the recommended approach.
 
-## Other
-
-This section has links directing you to best practices for managing Product and Sprint backlogs.  After reading through the best practices you should have a basic understanding for managing both product and sprint backlogs, how to create acceptance criteria for user stories, creating a definition of done and definition of ready for user stories and the basics around estimating user stories.
+## Links
 
 - [Product Backlog](https://scrumguides.org/scrum-guide.html#product-backlog)
 - [Sprint Backlog](https://scrumguides.org/scrum-guide.html#sprint-backlog)