pull base content,head:wwlpublishsync,into:0c7dc9a213245335bac4231fc12cfe38-live

Author: wwlpublish

.openpublishing.redirection.json

@@ -21724,6 +21724,71 @@
       "source_path": "learn-pr/azure/intro-to-azure-virtual-network-nat/7-summary.yml",
       "redirect_url": "/training/modules/intro-to-azure-nat-gateway/7-summary",
       "redirect_document_id": true
+    },
+    {
+      "source_path": "learn-pr/wwl-azure/configure-web-app-settings/7-manage-app-features.md",
+      "redirect_url": "https://learn.microsoft.com/training/modules/configure-web-app-settings/",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "learn-pr/wwl-azure/configure-web-app-settings/8-knowledge-check.md",
+      "redirect_url": "https://learn.microsoft.com/training/modules/configure-web-app-settings/7-knowledge-check",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "learn-pr/wwl-azure/configure-web-app-settings/9-summary.md",
+      "redirect_url": "https://learn.microsoft.com/training/modules/configure-web-app-settings/8-summary",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "learn-pr/wwl-azure/monitor-app-performance/3-application-insights-overview.md",
+      "redirect_url": "https://learn.microsoft.com/training/modules/monitor-app-performance/2-application-insights-overview",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "learn-pr/wwl-azure/monitor-app-performance/2-azure-monitor-overview.md",
+      "redirect_url": "https://learn.microsoft.com/training/modules/monitor-app-performance/",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "learn-pr/wwl-azure/monitor-app-performance/4-logs-based-metrics.md",
+      "redirect_url": "https://learn.microsoft.com/training/modules/monitor-app-performance/3-logs-based-metrics",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "learn-pr/wwl-azure/monitor-app-performance/5-app-instrumentation.md",
+      "redirect_url": "https://learn.microsoft.com/training/modules/monitor-app-performance/4-app-instrumentation",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "learn-pr/wwl-azure/monitor-app-performance/6-availability-tests.md",
+      "redirect_url": "https://learn.microsoft.com/training/modules/monitor-app-performance/5-availability-tests",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "learn-pr/wwl-azure/monitor-app-performance/7-application-map.md",
+      "redirect_url": "https://learn.microsoft.com/training/modules/monitor-app-performance/6-application-map",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "learn-pr/wwl-azure/monitor-app-performance/8-knowledge-check.md",
+      "redirect_url": "https://learn.microsoft.com/training/modules/monitor-app-performance/7-knowledge-check",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "learn-pr/wwl-azure/monitor-app-performance/9-summary.md",
+      "redirect_url": "https://learn.microsoft.com/training/modules/monitor-app-performance/8-summary",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "learn-pr/wwl-azure/work-with-cosmos-db/6-knowledge-check.md",
+      "redirect_url": "https://learn.microsoft.com/training/modules/work-with-cosmos-db/7-knowledge-check",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "learn-pr/wwl-azure/work-with-cosmos-db/7-summary.md",
+      "redirect_url": "https://learn.microsoft.com/training/modules/work-with-cosmos-db/8-summary",
+      "redirect_document_id": false
     }
   ]
 }

learn-pr/advocates/build-product-roadmaps/2-what-is-a-product-road-map.yml

@@ -1,9 +1,9 @@
 ### YamlMime:ModuleUnit
 uid: learn.build-product-road-maps.2-what-is-a-product-road-map
-title: What is a product road map?
+title: What is a product roadmap?
 metadata:
-  title: What is a product road map?
-  description: This unit describes the structure of a product road map.
+  title: What is a product roadmap?
+  description: This unit describes the structure of a product roadmap.
   author: czhu89
   ms.date: 04/16/2019
   ms.author: cazh
@@ -15,24 +15,24 @@ content: |
 quiz:
    title: Check your knowledge
    questions:
-   - content: "When is your product road map finished?"
+   - content: "When is your product roadmap finished?"
      choices:
      - content: At the end of each quarter
        isCorrect: false
      - content: At the end of the year
        isCorrect: false
      - content: Never
        isCorrect: true
-       explanation: "Product road maps are iterative, they're never finished."
+       explanation: "Product roadmaps are iterative, they're never finished."
      - content: When you launch the product
        isCorrect: false
-   - content: "Who should have input into the product road map?"
+   - content: "Who should have input into the product roadmap?"
      choices:
      - content: The product manager and all the engineers
        isCorrect: false
      - content: Everyone in your organization
        isCorrect: true
-       explanation: "Your product road map is a collaboration between many people in your organization including Product, Design, Engineering, Sales, Marketing, and Support."
+       explanation: "Your product roadmap is a collaboration between many people in your organization including Product, Design, Engineering, Sales, Marketing, and Support."
      - content: The product manager and the marketing team
        isCorrect: false
      - content: The product manager

learn-pr/advocates/build-product-roadmaps/includes/1-introduction.md

@@ -1,15 +1,15 @@
-You have an amazing idea. You’ve taken the core concepts of your idea and turned them into a prototype, a Minimum Viable Product (MVP). The prototype is the first pass. It’s not pretty, nor complete, and often not tested. Frank Robinson said when he coined the MVP term:
+You have an amazing idea. You’ve taken the core concepts of your idea and turned them into a prototype, a Minimum Viable Product (MVP). The prototype is the first pass. It’s not pretty or complete, and often not tested. Frank Robinson said when he coined the MVP term:
 
-> ... think big for the long term but small for the short term. Think big enough that the first product is a sound launching pad for it and its next generation and the road map that follows, but not so small that you leave room for a competitor to get the jump on you.
+> ... think big for the long term but small for the short term. Think big enough that the first product is a sound launching pad for it and its next generation and the roadmap that follows, but not so small that you leave room for a competitor to get the jump on you.
 
-Once you have your prototype how then do you turn it into a fully fledged product? Enter the product road map.
+Once you have your prototype, how then do you turn it into a fully fledged product? Enter the product roadmap.
 
-This module is an introduction, for Product Managers and Product Engineers, to developing product road maps. We present a high-level structure for road maps and a process for how to build them. We'll introduce you to a startup, Fabrikam, who are building a new AI-powered fashion app and take you through their process for building their first product road map. This module assume you're using, and understand, Agile methodology. But we're not opinionated about what kind of Agile you embrace. This module isn’t a definitive guide to product road maps but a starting point from which to experiment and learn what works for you.
+This module is an introduction, for Product Managers and Product Engineers, to developing product roadmaps. We present a high-level structure for roadmaps and a process for how to build them. We'll introduce you to a startup, Fabrikam, who is building a new AI-powered fashion app. We'll take you through their process for building their first product roadmap. This module assumes you're using and understand Agile methodology, but we're not opinionated about what kind of Agile you embrace. This module isn't a definitive guide to product roadmaps, but a starting point from which to experiment and learn what works for you.
 
 You’ll learn how to:
 
-* Describe the basic components and importance of product road maps.
-* Identify your product mission and the appropriate audience(s) for your road map
-* Structure a road map and choose a prioritization methodology appropriate for your product.
+* Describe the basic components and importance of product roadmaps.
+* Identify your product mission and the appropriate audience(s) for your roadmap
+* Structure a roadmap and choose a prioritization methodology appropriate for your product.
 
-By the end of this module you’ll be able to construct a product road that your team can use to build and manage your product.
+By the end of this module, you'll be able to construct a product roadmap that your team can use to build and manage your product.

learn-pr/advocates/build-product-roadmaps/includes/10-user-stories.md

@@ -1,67 +1,66 @@
 :::row:::
   :::column:::
-       ![Product road map user stories.](../media/user-stories.png)
+       ![Diagram of product roadmap user stories.](../media/user-stories.png)
   :::column-end:::
         :::column span="3":::
 
-User stories are the base artifacts for Agile planning. A user story is a high-level definition of a requirement. It should contain enough information that the requirement is understood, and a reasonable estimate of the effort required to build it can be made.
+User stories are the base artifacts for Agile planning. A user story is a high-level definition of a requirement. It should contain enough information that the requirement is understood and a reasonable estimate of the effort required to build it can be made.
 
-User stories are written throughout the development life cycle, but the core of them are written when you create an epic. Typically, the whole team involved, and often stakeholders from the business or even customers, and the stories are written in a workshop-like forum. Further stories will evolve as the epic proceeds, to address new requirements or to split existing stories that have become too complex. Some stories will even evolve into epics in their own right if they turn out to be complex or emerge as functionality worth extending.
+User stories are written throughout the development lifecycle, but most of them are written when you create an epic. Typically, the whole team is involved, often including stakeholders from the business or even customers. The stories are written in a workshop-like forum. Further stories will evolve as the epic proceeds to address new requirements or to split existing stories that have become too complex. Some stories will even evolve into epics in their own right if they turn out to be complex or emerge as functionality worth extending.
 
  :::column-end:::
 :::row-end:::
 
 A good user story contains:
 
-* Summary of the requirement, no more than one or two sentences.
-* Priority, to tell us how important the story is to the product.
-* Series of "stories" about the requirement, that describes what we expect from it.
-* Test of the story's success.
-* Estimate of the effort the story will take. 
+* A summary of the requirement, no more than one or two sentences.
+* A priority to tell us how important the story is to the product.
+* A series of "stories" about the requirement that describes what we expect from it.
+* A test of the story's success.
+* An estimate of the effort the story will take.
 
-Let’s look at an example story for our recommendation engine.
+Let’s look at an example story for our recommendation engine:
 
-* Summary: Build a content-based recommendation algorithm. 
+* Summary: Build a content-based recommendation algorithm.
 * Priority: 1
-* Stories
-  * As a customer, I want to see recommendations based on my prior purchases, so I can find the best items to buy.
-  * etc. ...
+* Stories:
+  * As a customer, I want to see recommendations based on my prior purchases so I can find the best items to buy.
 * Test: The algorithm returns three content-based recommendations for a customer’s user ID.
-* Estimate: 3 days.
+* Estimate: three days.
 
 ## Subject
 
-Our user story starts with a summary of the objective of the story, in our case building a recommendation algorithm.
+Our user story starts with a summary of the objective of the story; in our case, building a recommendation algorithm.
 
 ## Priority
 
-We give the story a priority, here `1`. This priority is derived from the prioritization frameworks we discussed earlier in the module. Remember in our 2x2 prioritization plot that stories in the top-left quadrant were the most important, here priority `1` would likely be one of those stories.
+We give the story a priority; here, `1`. This priority is derived from the prioritization frameworks we discussed earlier in the module. Remember in our 2x2 prioritization plot that stories in the top-left quadrant were the most important; here, priority `1` would likely be one of those stories.
 
 ## Stories
 
 We then list a series of "stories" about the feature we're building. Those "stories" typically follow a format something like:
 
 > As a < type of user >, I want < some goal > so that < some reason >
 
-They tell the story of what the user wants, expects, and needs from the requirement. 
+They tell the story of what the user wants, expects, and needs from the requirement.
 
 ## Test
 
 The test of the story is the acceptance criteria, which indicates successful completion of the story. In our case, our algorithm returning three recommendations for each user. Other tests might include the accuracy of the feature or its performance.
 
 ## Estimate
 
-The estimate is the amount of effort we believe the story will take to complete. Estimates can be complicated and hard to get right. There are [many](https://www.berteig.com/how-to-apply-agile/9-agile-estimation-techniques/) [ways](https://techbeacon.com/app-dev-testing/fast-estimation-better-approach-agile-estimation) of estimating work. A simple, initial, approach is to estimate the amount of time a story will take in days and/or hours. Initially, your estimates might be a little imprecise but as you complete stories you can validate your estimates against reality. This process will hopefully help you refine and develop more accurate estimates over time. 
+The estimate is the amount of effort we believe the story will take to complete. Estimates can be complicated and hard to get right. There are [many](https://www.berteig.com/how-to-apply-agile/9-agile-estimation-techniques/) [ways](https://techbeacon.com/app-dev-testing/fast-estimation-better-approach-agile-estimation) of estimating work. A simple initial approach is to estimate the amount of time a story will take in days and/or hours. Initially, your estimates might be a little imprecise, but as you complete stories, you can validate your estimates against reality. This process will hopefully help you refine and develop more accurate estimates over time.
 
 > [!WARNING]
-> Estimates can be contentious. It's often hard to estimate how much effort is involved in a story. If you or the team get it wrong then avoid recriminations. Instead, focus on identifying why the estimate was wrong and doing better next time. More learning, less blame.
+> Estimates can be contentious. It's often hard to estimate how much effort is involved in a story. If you or the team get it wrong, avoid recriminations. Instead, focus on identifying why the estimate was wrong and doing better next time; more learning, less blame.
 
 Your estimates also help you crudely ascertain how many people you need building your product. If you want to build 20 stories in a month that require more effort than your team can deliver, then you know you need to hire more people to build your product.
 
 ## Summary
 
 This story is a formal user story; many organizations use more lightweight and informal representations. If a story feels like it has too much detail, then the traditional approach is to split the story into smaller stories.
 
-![Product road map structure.](../media/structure.png)
+![Diagram of product roadmap structure.](../media/structure.png)
 
-From here, we can now also see the whole structure of a road map, and how each component, from user stories to the mission rolls up into the plan to build your product.
+From here, we can now also see the whole structure of a roadmap, and how each component from user stories to the mission rolls up into the plan to build your product.

learn-pr/advocates/build-product-roadmaps/includes/11-conclusion.md

@@ -1,7 +1,7 @@
-At the start of the module, you as Fabrikam's Product Manager, were trying to understand what features we needed to build next to make our AI-based fashion app a success. We needed to know what to build and how to communicate that to the product engineering team building the app and manage the product process.
+At the start of the module, you (as Fabrikam's Product Manager) were trying to understand what features we needed to build next to make our AI-based fashion app a success. We needed to know what to build, how to communicate that to the product engineering team building the app, and how to manage the product process.
 
-To help achieve this goal, we implemented a product road map. The road map allows us to see the path forward for the app. Our road map provides a focal point for the product engineering team to ensure they know not only what we're building but why, the problem we're trying to solve as a company, and how we intend to solve it. Without it, we don't have a mechanism to manage our product process and no means of ensuring we build the product we need and our customers want.
+To help achieve this goal, we implemented a product roadmap. The roadmap allows us to see the path forward for the app. Our roadmap provides a focal point for the product engineering team to ensure they know not only what we're building but why, the problem we're trying to solve as a company, and how we intend to solve it. Without it, we don't have a mechanism to manage our product process, nor did we have any means of ensuring we build the product we need and our customers want.
 
-With our product road map in place, we can manage both the day-to-day product process and have the data we need to keep our executive team, investors, and customers informed about our progress. Using prioritization we know what the most important features that we should build next are and using our estimates we can understand how long that might take.
+With our product roadmap in place, we can manage both the day-to-day product process and have the data we need to keep our executive team, investors, and customers informed about our progress. Using prioritization, we know what the most important features are that we should build next, and using our estimates, we can understand how long that might take.
 
-Fabrikam is now set up for product success and hopefully their fashion app will be a market success!
+Fabrikam is now set up for product success, and hopefully their fashion app will be a market success!