fixing grammar, wording

_data/navbar.yml

@@ -38,7 +38,7 @@ assigned:
               show_in_menu: true
               show_in_footer: false
           -
-              text: Building prorotypes
+              text: Building prototypes
               href: pages/strategies/prototyping.md
               show_in_menu: true
               show_in_footer: false

_strategies/agile-development.md

@@ -20,11 +20,11 @@ In any complex system, needs change, evolve, or are discovered over time. Instea
 
 To help this process, we pair identifying goals at a higher level (an “epic” in agile terminology) with an ongoing user research process. These epics describe the user need, not the solution.  For example, a user story might be: “As a caseworker, I want to see all my current cases and next steps so I know what I need to do next, and when I need to do it.” We wouldn't write: “The system shall display the next step next to each case in a grid on the main screen.” Through the user research and usability testing throughout the life of the product development, these epics are turned into a set of increasingly-specific user stories. Each story should be designed, researched, developed and tested within a single sprint. We validate each implemented story with usability testing with real end users, and use the feedback from that work to generate additional backlog user stories.
 
- We prioritize user stories continuously and do not focus on what is in the development backlog beyond what can be done in a month in the future.
+ We prioritize user stories continuously and do not focus on what is in the development backlog beyond what can be done within the next month.
 
 ### Agile development requires a shift in how you understand the costs of software development.
 
-The traditional “waterfall” method of software development assumes that software can be built once for a large, one-time investment. In practice, this is untrue, because requirements can rarely be fully known and change constantly. The product team's understanding of users' needs arise through research and testing which deepens but shortens your teams forecasting of costs..
+The traditional “waterfall” method of software development assumes that software can be built once for a large, one-time investment. In practice, this is untrue, because requirements can rarely be fully known and change often. The product team's understanding of users' needs arise through research and testing, allowing you to provide reasonable cost estimates in the short-term.
 
 Ultimately, the state’s investment should be measured in working software, not phase documents or milestones. Only working systems are of value to real constituents. Based on that premise, teams are only able to measure the success of a waterfall project after most costs have been incurred, because that is the first time working software is delivered. This is a huge risk. Agile projects allow the state to measure success at more regular intervals, and reduce the overall risk to the state.
 

_strategies/prototyping.md

@@ -30,7 +30,7 @@ The government should leverage prototypes to obtain user feedback, validate tech
 
 If the logic behind modular procurement is to break down large projects into smaller chunks to reduce risk, employ this same approach when prototyping. Instead of thinking of a prototype as an immutable whole, consider how it can be broken into pieces to address assumptions about customer value and technical risks. Don't obsess about documentation, but highlight to the  what assumption this prototype was meant to assess, and how this tool measured up against those hypothesis.
 
-For example, consider using a boilerplate app (or simple demo app) to support development or to build out a minimal [DevOps pipeline](/devops), can help you see where the bottlenecks to agile development will likely occur before a vendor is brought on.
+For example, consider using a boilerplate app (or simple demo app) to support development, or building out a minimal [DevOps pipeline](/devops) pipeline to help identify bottlenecks in your process before a vendor is brought on.
 
 ### Help vendors, don’t handcuff them
 
@@ -50,9 +50,9 @@ One of the goals of Acq engagements (and [18F engagements in general](https://pa
 
 It’s important to understand security requirements in the client environment that can impact prototyping work.
 
-Does you have the policy and technical infrastructure in place to support prototyping? Is a full System Security Plan required to build a prototype that isn’t intended to be deployed to a production environment or require ongoing O&M?
+Do you have the policy and technical infrastructure in place to support prototyping? Is a full System Security Plan required to build a prototype that isn’t intended to be deployed to a production environment or require ongoing O&M?
 
-Does you have the technical infrastructure in place to support prototyping? Is test data available for use in building a prototype? Is there an environment where test apps or prototypes can be efficiently deployed?
+Do you have the technical infrastructure in place to support prototyping? Is test data available for use in building a prototype? Is there an environment where test apps or prototypes can be efficiently deployed?
 
 Consider adding someone that can represent the client’s security office to the product team. Give this person a seat at the table from day one.
 

_strategies/using-cots.md

@@ -12,7 +12,7 @@ image-credit: https://www.flickr.com/photos/butterflysha/
 
 In some cases, if there is a COTS system that will fit your end-user needs, then there may be an opportunity for cost savings. 
 
-### Fully assess whether commercial off-the-shelf (COTS) solutions fit your projects' needs.
+### Fully assess whether commercial off-the-shelf (COTS) solutions fit your project's needs.
 
 First determine, whether the COTS product will be to deliver a unique government service with public users, or is an intermediate tool for developers.