fix(guide): simplify directory structure

guide/english/agile/acceptance-criteria/index.md

@@ -0,0 +1,24 @@
+---
+title: Acceptance Criteria
+---
+## Acceptance Criteria
+
+The User Story, as an item in your backlog, is a placeholder for a conversation. In this conversation,
+the Product Owner and the Delivery Team reach an understanding on the desired outcome.
+
+The Acceptance Criteria tells the Delivery Team how the code should behave. Avoid writing the **"How"** of the User Story; keep to the **"What"**.
+If the team is following Test Driven Development (TDD), it may provide the framework for the automated tests.
+The Acceptance Criteria will be the beginnings of the test plan for the QA team.
+
+Most importantly, if the story does not meet each of the Acceptance Criteria, then the Product Owner should not be accepting the story at the end of the iteration.
+
+Acceptance criteria can be viewed as an instrument to protect the Delivery Team. When the Delivery Team commits to a fixed set of stories in the Sprint planning they commit to fixed set of acceptance criteria as well. This helps to avoid scope creep.
+
+Consider the following situation: when accepting the user story the Product Owner suggests adding something that was not in the scope of the User story. In this case the Delivery team is in the position to reject this request (however small it might be) and ask the Product owner to create a new User story that can be taken care of in another Sprint. 
+
+
+#### More Information:
+
+Nomad8 provides an [FAQ on Acceptance Criteria](https://nomad8.com/acceptance_criteria/)
+
+Leading Agile on [Acceptance Criteria](https://www.leadingagile.com/2014/09/acceptance-criteria/)

guide/english/agile/acceptance-testing/index.md

@@ -0,0 +1,140 @@
+---
+title: Acceptance Testing
+---
+
+## Acceptance Testing
+
+Acceptance testing, a testing technique performed to determine whether or not the software system has met the requirement specifications. The main purpose of this test is to evaluate the system's compliance with the business requirements and verify if it is has met the required criteria for delivery to end users.
+
+In software development, user acceptance testing (UAT) - also called beta testing, application testing, and end user testing - is a phase of software development in which the software is tested in the "real world" by the intended audience.In engineering and its various subdisciplines, acceptance testing is a test conducted to determine if the requirements of a specification or contract are met. 
+
+There are various forms of acceptance testing:
+
+->User acceptance Testing
+
+->Business acceptance Testing
+
+->Alpha Testing
+
+->Beta Testing
+
+#Acceptance Criteria
+Acceptance criteria are defined on the basis of the following attributes
+
+->Functional Correctness and Completeness
+
+->Data Integrity
+
+->Data Conversion
+
+->Usability
+
+->Performance
+
+->Timeliness
+
+->Confidentiality and Availability
+
+->Installability and Upgradability
+
+->Scalability
+
+->Documentation
+
+#Acceptance Test Plan - Attributes
+The acceptance test activities are carried out in phases. Firstly, the basic tests are executed, and if the test results are satisfactory then the execution of more complex scenarios are carried out.
+
+The Acceptance test plan has the following attributes:
+
+->Introduction
+
+->Acceptance Test Category
+
+->Operation Environment
+
+->Approach
+
+->Feature to be tested
+
+->Feature not to be tested
+
+->Responsibilities
+
+->Test case ID
+
+->Test Title
+
+->Test Objective
+
+->Test Procedure
+
+->Test Schedule
+
+->Resources
+
+=>The acceptance test activities are designed to reach at one of the conclusions:
+
+Accept the system as delivered
+
+Accept the system after the requested modifications have been made
+
+Do not accept the system
+
+#Acceptance Test Report - Attributes
+The Acceptance test Report has the following attributes:
+
+->Report Identifier
+
+->Summary of Results
+
+->Variations
+
+->Recommendations
+
+->Summary of To-DO List
+
+->Approval Decision
+=======
+Acceptance Testing focuses on checking if the developed software meets all the requirements. Its main purpose is to check if the solution developed meets the user expectations.
+
+<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
+
+Acceptance Testing is a well-established practice in software development. Acceptance Testing is a major part of Functional Testing of your code.
+
+An Acceptance Test tests that the code performs as expected i.e. produces the expected output, given the expected inputs.
+
+An Acceptance Test are used to test relatively bigger functional blocks of software aka Features.
+
+### Example
+You have created a page that requires the user to first enter their name in a dialog box before they can see the content. You have a list of invited users, so any other users will be returned an error.
+
+There are multiple scenarios here such as: 
+- Every time you load the page, you need to enter your name.
+- If your name is in the list, the dialog will disappear and you will see the article.
+- If your name is not in the list, the dialog box will show an error.
+
+You can write Acceptance Tests for each of these sub-features of the bigger dialog box feature
+
+Aside from the code that handles the infrastructure of how the test will be executed, your test for the first scenario could look like (in pseudocode):
+
+Given that the page is opened
+The dialog box should be visible
+And The dialog box should contain an input box
+And The input box should have placeholder text "Your name, please!"
+
+### Notes
+
+Acceptance Tests can be written in any language and run using various tools available that would take care of the infrastructure mentioned above e.g. Opening a browser, loading a page, providing the menthods to access elements on the page, assertion libraries and so on.
+
+Every time you write a piece of software that will be used again (even by yourself), it helps to write a test for it. When you yourself or another makes changes to this code, running the tests will ensure that you have not broken existing functionality.
+
+It is usually performed by the users or the Subject Matter Experts. It is also called as User Acceptance Testing (UAT). UAT involves most common real life scenarios. Unlike system testing, it does not focus on the errors or crashes, but on the functionality. UAT is done at the end of the testing life-cycle and will decide if the software is moved to the next environment or not.
+
+A good way of defining which acceptance tests should be written is to add acceptance criteria to a user story. With acceptance criteria, you can define when a user story is ready to deploy and the issue completed to your wishes.
+
+In an Agile project it is important for the team to have acceptance criteria defined for all user stories. The Acceptance Testing work will use the defined criteria for evaluating the delivered functionality. When a story can pass all acceptance criteria it is complete. 
+
+Acceptance testing can also validate if a completed epic/story/task fulfills the defined acceptance criteria. In contrast to definition of done, this criteria can cover specific business cases that the team wants to solve. This provides a good measurement of work quality.
+
+#### More Information:
+- [International Software Testing Qualifications Board](http://www.istqb.org/)

guide/english/agile/actual-time-estimation/index.md

@@ -0,0 +1,53 @@
+---
+title: Actual Time Estimation
+---
+## Actual Time Estimation
+
+Actual Time Estimation is the process of predicting the most realistic amount of effort (expressed in terms of person-hours or money) required to develop or maintain software based on incomplete, uncertain and noisy input. Effort estimates may be used as input to project plans, iteration plans, budgets, investment analyses, pricing processes and bidding rounds.
+
+### State-of-practice
+
+Published surveys on estimation practice suggest that expert estimation is the dominant strategy when estimating software development effort.
+
+Typically, effort estimates are over-optimistic and there is a strong over-confidence in their accuracy. The mean effort overrun seems to be about 30% and not decreasing over time. For a review of effort estimation error surveys, see. However, the measurement of estimation error is problematic, see Assessing the accuracy of estimates. The strong overconfidence in the accuracy of the effort estimates is illustrated by the finding that, on average, if a software professional is 90% confident or “almost sure” to include the actual effort in a minimum-maximum interval, the observed frequency of including the actual effort is only 60-70%.
+
+Currently the term “effort estimate” is used to denote as different concepts as most likely use of effort (modal value), the effort that corresponds to a probability of 50% of not exceeding (median), the planned effort, the budgeted effort or the effort used to propose a bid or price to the client. This is believed to be unfortunate, because communication problems may occur and because the concepts serve different goals.
+
+### History
+
+Software researchers and practitioners have been addressing the problems of effort estimation for software development projects since at least the 1960s; see, e.g., work by Farr and Nelson.
+
+Most of the research has focused on the construction of formal software effort estimation models. The early models were typically based on regression analysis or mathematically derived from theories from other domains. Since then a high number of model building approaches have been evaluated, such as approaches founded on case-based reasoning, classification and regression trees, simulation, neural networks, Bayesian statistics, lexical analysis of requirement specifications, genetic programming, linear programming, economic production models, soft computing, fuzzy logic modeling, statistical bootstrapping, and combinations of two or more of these models. 
+
+The perhaps most common estimation methods today are the parametric estimation models COCOMO, SEER-SEM and SLIM. They have their basis in estimation research conducted in the 1970s and 1980s and are since then updated with new calibration data, with the last major release being COCOMO II in the year 2000. The estimation approaches based on functionality-based size measures, e.g., function points, is also based on research conducted in the 1970s and 1980s, but are re-calibrated with modified size measures and different counting approaches, such as the use case points or object points in the 1990s and COSMIC in the 2000s.
+
+Actual time estimation is a time-based method of estimating development work.  
+
+It is critically important to be able to estimate the time-to-completion of an Agile project, unfortunately, it is also one of the most difficult parts of planning an Agile project. 
+
+Its intent is to best approximate the amount of time required to complete a given development task. 
+
+One technique you may use is to estimate the time it will take to complete user stories. When you are doing this, remember to consult with other members of your agile team. For each user story, make sure that you estimate a time that is realistic and feasible, yet not so much that the client is overcharged for simple work. Consult members of your team so that you may be able to leverage their expertise to be able to understand how much work is required and how long it will take. When you have a consensus for each user story, you can add up the times to come up with a time estimation. 
+
+As the requirements of the project change over time, you can update the estimate. If a project loses some resources originally allocated to it, you may need to cut user stories to be able to complete them in the same amount of total time. Similarly, if you want to improve the quality of the app, you may need to allocate more time to each user story to make sure your team has time to finish the app with the desired quality.
+
+Generally, these estimates are calculated using ideal engineering hours.
+
+Examples: 
+
+**This task will be complete in 10 days.**
+
+Or… 
+
+**This task will be complete by January 10th.**
+
+Or… 
+
+**This task will require 25 development hours for completion.**
+
+### More Information:
+
+- [Agile Constraints](http://www.brighthubpm.com/agile/50212-the-agile-triangle-value-quality-and-constraints/)
+
+- [How do you estimate on an Agile project?](http://info.thoughtworks.com/rs/thoughtworks2/images/twebook-perspectives-estimation_1.pdf)
+

guide/english/agile/alignment/index.md

@@ -0,0 +1,15 @@
+---
+title: Alignment
+---
+## Alignment
+
+This is a stub. <a href='https://github.com/freecodecamp/guides/tree/master/src/pages/agile/alignment/index.md' target='_blank' rel='nofollow'>Help our community expand it</a>.
+
+<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
+
+<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds  -->
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+
+

guide/english/agile/application-lifecycle-management/index.md

@@ -0,0 +1,26 @@
+---
+title: Application Lifecycle Management
+---
+## Application Lifecycle Management
+
+Application Lifecycle Management (ALM), while commonly associated with Software Development Lifecycle (SDLC) is a broader perspective that aligns better with the concept of Product Lifecycle. The development (SDLC) is only a portion of the Application's Lifecycle and therefore is represented as part of the ALM. 
+
+ALM can be divided into three distinct areas: Governance, Development, and Operations:
+
+Governance: Encompasses all of the decision making and project management for this application, extends over the entire existance of the application.
+
+Development: Process (SDLC) of actually creating the application. For most applications, the development process reappears again several more times in the application’s lifetime, including bug fixes, improvements and new versions.
+
+Operations: Work required to run and manage the application,typically begins shortly before deployment, then runs continuously until application retirement. Overlaps at times with Development.  
+
+Tools can be used to manage ALM; some of the more popular options include:
+
+* Atlassian [JIRA](http://atlassian.com/software/jira)
+* CA Technologies [Rally](http://ca.com/us.html)
+* [Thoughtworks](http://thoughtworks.com/products)
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+InfoQ - Gartner and Software Advice examine [Agile Lifecycle Management Tools](http://www.infoq.com/news/2015/02/agile-management-tools/)
+
+

guide/english/agile/architectural-runway/index.md

@@ -0,0 +1,6 @@
+---
+title: Architectural Runway
+---
+The architectural runway is setting everything up the program would need before the project is started. This allows developers to hit the ground running.
+
+

guide/english/agile/backlog-emergence-and-grooming/index.md

@@ -0,0 +1,20 @@
+---
+title: Backlog Emergence and Refinement
+---
+## Backlog Emergence and Refinement
+
+Product backlog refinement is an on going process that needs to be in sync with the product discovery process. Generally, a Scrum team will collaboratively refine product backlog items for the next two to three sprints.
+
+A product owner (individual responsible for clarifying a sprint's goal) defines the scope of the upcoming sprints by identifying and triaging the most valuable user stories in the product backlog. A product owner is more than a glorified project manager of the product backlog, and performs more roles than simply user stories on behalf of stakeholders.
+
+From the Scrum Guide:
+Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised.
+
+The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion. The objective of refinement is to have enough Product Backlog items "Ready" for the next Sprint's Sprint Planning. Generally, a scrum team will collaboratively refine product backlog items for the next two to three sprints.
+
+Backlog emergence and refinement are essential tasks for every scrum team. The Product Owner defines the scope of the upcoming sprints by identifying and triaging the most valuable user stories in the product backlog. Although the Product Owner is in charge of keeping the product backlog at peak value delivery, they need the assistance of the entire Scrum Team to do so. Changing the Sprint Backlog is part of the ongoing Sprint and is not considered Refinement. 
+
+#### More Information:
+- [Optimizing Product Backlog Refinement](https://www.scrum.org/resources/blog/optimizing-product-backlog-refinement)
+- Scrum Guide (http://www.scrumguides.org/)
+

guide/english/agile/backlog-item-effort/index.md

@@ -0,0 +1,15 @@
+---
+title: Backlog Item Effort
+---
+## Backlog Item Effort
+
+This is a stub. <a href='https://github.com/freecodecamp/guides/tree/master/src/pages/agile/backlog-item-effort/index.md' target='_blank' rel='nofollow'>Help our community expand it</a>.
+
+<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
+
+<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds  -->
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+
+

guide/english/agile/behavior-driven-development/index.md

@@ -0,0 +1,62 @@
+---
+title: Behavior Driven Development
+---
+## Behavior Driven Development
+
+Behavior Driven Development (BDD) is a software development process that emerged from ![Test Driven Development (TDD)](../test-driven-development/index.md).
+Behavior Driven Development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.
+It is a software development methodology in which an application is specified and designed by describing how its behavior should appear to an outside observer.
+
+Although BDD is principally an idea about how software development should be managed by both business interests and technical insight, the practice of BDD does assume the use of specialized software tools to support the development process.
+
+Although these tools are often developed specifically for use in BDD projects, they can be seen as specialized forms of the tooling that supports test-driven development. The tools serve to add automation to the ubiquitous language that is a central theme of BDD.
+
+BDD focuses on:
+- Where to start in the process
+- What to test and what not to test
+- How much to test in one go
+- What to call the tests
+- How to understand why a test fails
+
+At the heart of BDD is a rethinking of the approach to the unit testing and acceptance testing that naturally arise with these issues. 
+For example, BDD suggests that unit test names be whole sentences starting with a conditional verb ("should" in English for example) and should be written in order of business value. 
+Acceptance tests should be written using the standard agile framework of a user story: "As a _role_ I want _feature_ so that _benefit_".
+Acceptance criteria should be written in terms of scenarios and implemented as classes: Given _initial context_, when _event occurs_, then _ensure some outcomes_.
+
+Example
+
+```
+Story: Returns go to stock
+
+As a store owner
+In order to keep track of stock
+I want to add items back to stock when they're returned.
+
+Scenario 1: Refunded items should be returned to stock
+Given that a customer previously bought a black sweater from me
+And I have three black sweaters in stock.
+When he returns the black sweater for a refund
+Then I should have four black sweaters in stock.
+
+Scenario 2: Replaced items should be returned to stock
+Given that a customer previously bought a blue garment from me
+And I have two blue garments in stock
+And three black garments in stock.
+When he returns the blue garment for a replacement in black
+Then I should have three blue garments in stock
+And two black garments in stock.
+```
+Along with it are some Benefites:
+
+1. All development work can be traced back directly to business objectives.
+2. Software development meets user need. Satisfied users = good business.
+3. Efficient prioritisation - business-critical features are delivered first.
+4. All parties have a shared understanding of the project and can be involved in the communication.
+5. A shared language ensures everyone (technical or not) has thorough visibility into the project’s progression.
+6. Resulting software design that matches existing and supports upcoming business needs.
+7. Improved quality code reducing costs of maintenance and minimising project risk.
+ 
+## More Information
+* Wiki on <a href='https://en.wikipedia.org/wiki/Behavior-driven_development' target='_blank' rel='nofollow'>BDD</a>
+* A well-known Behavior Driven Development (BDD) framework is [Cucumber](https://cucumber.io/). Cucumber supports many programming languages and can be integrated with a number of frameworks; for example, [Ruby on Rails](http://rubyonrails.org/), [Spring Framework](http://spring.io/) and [Selenium](http://www.seleniumhq.org/)
+* https://inviqa.com/blog/bdd-guide

guide/english/agile/build-measure-learn/index.md

@@ -0,0 +1,24 @@
+---
+title: Build Measure Learn
+---
+## Build Measure Learn
+
+The Build-Measure-Learn loop is a method used to build the right product. Coined in the "Lean Startup" book by Eric Reis, the loop enables rapid experimenting, in the sole purpose of achieving market fit. In other words, it is a powerful system to validate assumptions concerning a product you set out to deliver. Breaking down the loop, it consists of the following parts:
+
+![build-measure-learn-loop](https://steveblank.files.wordpress.com/2015/05/ideas-build-code-measure.jpg)
+
+### Idea
+Each loop starts with an idea that will supply business value to some users. Such idea must be consisted of a vision for a product - which will direct you at what to build, and a metric that will point out to whether your assumptions about the business value were correct.
+
+### Build
+To validate your idea, you set out to build a Minimal Viable Product (MVP), combined with predefined metrics (one is preferred), whose purpose is to validate your theory, and help you decide whether you should preserve or pivot.
+
+### Measure
+This stage is focused on collecting data & metrics from the MVP.
+
+### Learn
+Next, using the data collected, a decision has to be made, whether or not your product is used by users and so you should preserve, or whether users are not interested in the product, and as such you must pivot. The learn phase is therefore ending with an idea (either how to expand the product, or how to pivot from the original product), applicable for the next Build Measure Learn loop.
+
+#### More Information:
+[Why Build, Measure, Learn – isn’t just throwing things against the wall to see if they work – the Minimal Viable Product](https://steveblank.com/2015/05/06/build-measure-learn-throw-things-against-the-wall-and-see-if-they-work/)
+[The Build-Measure-Learn Feedback Loop](https://www.mindtools.com/pages/article/build-measure-learn.htm)

guide/english/agile/burndown-charts-and-burnup-charts/index.md

@@ -0,0 +1,23 @@
+---
+title: Burndown Charts and Burnup Charts
+---
+## Burndown Charts and Burnup Charts
+
+Burndown and burnup charts are used to measure progress of a project-- usually a development sprint under the Agile methodology. Both charts visually represent work versus time. 
+
+Burndown charts show how much work is left to be done versus the amount of time remaining. The Y axis represents work left to be done-- usually relating to a time estimate assigned to each task, e.g. story points-- and the X axis represents time left. Two lines are used; the first-- "Ideal Work Remaining Line"-- represents an ideal burndown, where each day an amount of work proportional to the total amount of time is completed, resulting in a straight line. The second "Actual Work Remaining Line" is used to plot actual progress as taks move through development to a done state. An example of a burndown chart is shown below.
+
+![alt text](https://upload.wikimedia.org/wikipedia/commons/8/8c/Burn_down_chart.png "Image Source: Wikipedia")
+
+Many Scrum Teams use burndown charts in order to see how they are doing during the sprint. Having an even and steady burndown might be an indicator that the stories are small and manageable. If a team notices in the middle of a sprint that the "Actual Work Remaining Line" is above the "Ideal Work Remaining Line" they can make adjustments to the scope: stories can be taken out of the sprint or the scope of stories can be made smaller. Looking at the burndown during the retrospective in the end of the sprint might spark some interesting discussions and result in process improvements.
+
+Burnup charts are very similar, but they show the work that has been completed versus the total amount of work and time remaining. Three lines are used-- an ideal line, a completed work line, and a total work line. In this chart, the total work line should be somewhat steady across the top of the chart, and is a good representation of scope change. The completed work line should move steadily up towards the total work line for the amount of time in the project-- its ideal trajectory is shown by the ideal line. An example is shown below.
+
+![alt text](https://media.licdn.com/mpr/mpr/shrinknp_800_800/AAEAAQAAAAAAAAljAAAAJGQ1ZDI2NzRkLWExYTQtNGI2OS1hZmZjLTM1NGMzYTk1NTEyNg.png "Image Source: Ala'a Elbeheri, LinkedIn")
+
+
+#### More Information:
+<a href='https://en.wikipedia.org/wiki/Burn_down_chart' target='_blank' rel='nofollow'>Burndown Charts- Wikipedia</a>
+<a href='https://www.linkedin.com/pulse/burn-up-vs-down-chart-alaa-el-beheri-cisa-rmp-pmp-bcp-itil/' target='_blank' rel='nofollow'>Burn up vs burn down chart- LinkedIn</a>
+
+

guide/english/agile/business-value/index.md

@@ -0,0 +1,10 @@
+---
+title: Business Value
+---
+## Business Value
+
+Business Value is the focus of agile delivery. The agile team is charged with evaluating the business value of all work.
+
+Business value describes what the customer will get for a specific piece of work.
+
+This value is discovered through conversations with the customer and analysis of the work involved. Business stakeholders may have data that quantifies the value of a given feature that has been requested. A product owner will use the various sources of information available and devote significant time to understanding, evaluating, and prioritizing the value the customer will receive for a given piece of work. 

guide/english/agile/chickens-versus-pigs/index.md

@@ -0,0 +1,24 @@
+---
+title: Chickens Versus Pigs
+---
+## Chickens Versus Pigs
+
+"Chickens versus Pigs" refers to a story about a chicken and a pig, where the chicken proposes they open a restaurant called "Ham-n-Eggs".
+The pig refuses, because while the chicken just needs to lay eggs, the pig has more at stake.
+
+In an Agile software development project, the software developer is the pig. If you fail to complete the job, or fail to do it well,
+you have a lot at stake. This could be your reputation, or maybe even your position. Other team members might also be considered pigs, 
+depending on how much they have at stake. 
+
+On the other hand, many team members are chickens. For example, the client or a high-level project manager would not really be impacted
+by the failure of the project. They are interested in its success, and might make contributions, but have lower stakes and thus
+have significantly less commitment to the project. 
+
+You should strive to be a pig rather than a chicken. You can benefit from (but should not rely on) the chickens in order to minimize risk and
+guarantee the project is delivered as efficiently as possible.
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+
+<a href='http://www.agilejedi.com/chickenandpig'>Agile Jedi: The Story of the Chicken and Pig</a>  
+<a href='https://en.wikipedia.org/wiki/The_Chicken_and_the_Pig'>Wikipedia: The Chicken and the Pig</a>

guide/english/agile/code-smells/index.md

@@ -0,0 +1,20 @@
+---
+title: Code Smells
+---
+## Code Smells
+
+A Code Smell in computer programming is a surface indication that there might be a problem regarding your system and the quality of your code. This problem might require refactoring to be fixed.
+
+It is important to understand that smelly code works, but is not of good quality.
+
+#### Examples
+1. Duplicated code - Blocks of code that have been replicated across the code base. This may indicate that you need to generalize the code into a function and call it in two places, or it may be that the way the code works in one place is completely unrelated to the way it works in another place, despite having been copied.
+2. Large classes - Classes having too many lines of code. This may indicate that the class is trying to do too many things, and needs to be broken up into smaller classes.
+
+#### More Information:
+* _Refactoring: Improving the Design of Existing Code - Kent Beck, Martin Fowler_
+* _Clean Code: A Handbook of Agile Software Craftsmanship - Martin, Robert C. (2009)._
+* [Code Smells on Wikipedia](https://en.wikipedia.org/wiki/Code_smell)
+* [Code Smells on Jeff Atwood's Blog (Coding Horror)](https://blog.codinghorror.com/code-smells/)
+* [Code Smells on Ward Cunningham's C2 Wiki](http://wiki.c2.com/?CodeSmell)
+* [Martin Fowler - Code Smell](https://martinfowler.com/bliki/CodeSmell.html)

guide/english/agile/colocation-vs-distributed/index.md

@@ -0,0 +1,11 @@
+---
+title: Collocation Vs Distributed
+---
+## Collocation Vs Distributed
+- Co-located refers to a team that sits together; same office. Ideally, everyone sitting together in adjacent offices or an open workspace.
+- Distributed team members are scattered geographically; different buildings, cities, or even countries.
+In case of distributed team, infrastructure should facilitate processes in order to resolve time difference and distance between team members, thus providing an efficient way of working altogether. 
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+
+

guide/english/agile/continuous-delivery/index.md

@@ -0,0 +1,11 @@
+---
+title: Continuous Delivery
+---
+## Continuous Delivery
+
+Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.<sup><a href='https://en.wikipedia.org/wiki/Extreme_programming' target='_blank' rel='nofollow'>1</a></sup>
+
+It aims at building, testing, and releasing software faster and more frequently. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery. Continuous delivery means that the team ensures every change can be deployed to production but may choose not to do it, usually due to business reasons.
+
+
+

guide/english/agile/continuous-deployment/index.md

@@ -0,0 +1,14 @@
+---
+title: Continuous Deployment
+---
+
+## Continuous Deployment
+
+Continuous Deployment is a modern software engineering process which is considered part of a DevOps environment. It involves teams of developers producing, updating and releasing code in very short cycles. This means developers commit smaller amounts of code, much more often.
+
+The goal of Continuous Deployment is to have code in a constant reliable and deployable state to enable this code to be released at any time. This process aims to release code more quickly. To achieve continuous deployment, a development team relies on infrastructure that automates and instruments the various steps leading up to deployment. This is quite often called Infrastructure as Code (IaC). 
+
+Two main benefits of Continuous Deployment include an earlier return on investment for each feature after it is developed due to the lower release times as well as earlier feedback on new features. 
+
+Other benefits to Continuous Deployment include improved code quality due to less bugs making it to production, more reliable code releases and a much lower time to market.
+

guide/english/agile/continuous-integration/index.md

@@ -0,0 +1,56 @@
+---
+title: Continuous Integration
+---
+## Continuous Integration
+
+At it's most basic, continuous integration (CI) is an agile development methodology in which developers regularly merge their code directly to the main source, usually a remote `master` branch. In order to ensure that no breaking changes are introduced, a full test suite is run on every potentiual build to regression test the new code, i.e. test that the new code does not break existing, working features.
+
+This approach requires good test coverage of the code base, meaning that a majority, if not all, of the code has tests which ensure its features are fully functional. Ideally continuous integration would be practiced together with full <a href='https://guide.freecodecamp.org/agile/test-driven-development' target='_blank' rel='nofollow'>Test-Driven Development</a>.
+
+### Main Steps
+
+The following basic steps are necessary to do the most standard current approach to continuous integration.
+
+1. Maintain a central repo and an active `master` branch.
+
+There has to be a code repository for everyone to merge into and pull changes from. This can be on Github or any number of code-storage services.
+
+2. Automate the build.
+
+Using NPM scripts or more complex build tools like Yarn, Grunt, Webpack, or <a href='https://guide.freecodecamp.org/developer-tools/gulp' target='_blank' rel='nofollow'>Gulp</a>, automate the build so that a single command can build a fully functional version of the product, ready to be deployed in a production environment. Better yet, include deployment as part of the automated build!
+
+3. Make the build run all the tests.
+
+In order to check that nothing in the new code breaks existing functionality, the full test suite needs to be run and the build needs to fail if any tests within it fail.
+
+4. Everyone has to merge changes to `master` every day.
+
+5. Every merge into `master` has to be built and fully tested.
+
+### Best Practices
+
+There are further best practices that make the best use of what CI has to offer and the challenges it presents, such as:
+
+1. Keep the build fast, so that lots of developer time isn't wasted waiting for a build.
+
+2. Test the build in a full clone of the production environment.
+
+If you have, for example, an app deployed on something like Heroku or Digital Ocean, have a separate test deployment there that you can deploy test builds to, to make sure they work not just in tests but in a real production environment. This test environment should be functionally identical to the actual production environment, in order to ensure the test is accurate.
+
+3. Make it easy to stay up to date.
+
+Coders should pull regularly from the `master` branch to keep integrating their code with the changes from their team. The repo should also be made available to stakeholders like product managers, company executives, or sometimes key clients, so that everyone is easily able to see progress.
+
+4. Keep records of builds, so that everyone can see the results of any given build, whether it succeeded or failed, and who or what introduced new changes.
+
+5. Automate deployment.
+
+Keep your app fully up-to-date with any new changes by automating deployment in the production environment as the final stage of the build process, once all tests have passed and the test deployment in the production environment clone has succeeded.
+
+### CI Services
+
+Lots of services exists to handle the process of continuous integration for you, which can make it a lot easier to establish a solid CI pipeline, or build process. When evaluating these, take into account factors like budget, build speed, and what kind of project you're working on. Some services, like <a href='https://travis-ci.org' target='_blank' rel='nofollow'>Travis CI</a> offer free services for open-source projects, which can make them an easy choice for projects like that, but they might have slower builds than other services, like <a href='https://circleci.com/' target='_blank' rel='nofollow'>Circle CI</a> or <a href='https://codeship.com/' target='_blank' rel='nofollow'>Codeship</a>, to name just a few.
+
+#### More Information:
+The Wikipedia entry on <a href='https://en.wikipedia.org/wiki/Continuous_integration' target='_blank' rel='nofollow'>Continuous Integration</a>.
+

guide/english/agile/cross-functional-teams/index.md

@@ -0,0 +1,42 @@
+---
+title: Cross Functional Teams
+---
+
+## Cross Functional Teams
+
+A cross-functional team is a group of people with different functional expertise working toward a common goal.
+
+Typically, it includes employees from all levels of an organization. Members may also come from outside an organization (in particular, from suppliers, key customers, or consultants). Cross-functional teams often function as self-directed teams assigned to a specific task which calls for the input and expertise of numerous departments. 
+
+Assigning a task to a team composed of multi-disciplinary individuals increases the level of creativity and out of the box thinking. 
+
+Each member offers an alternative perspective to the problem and potential solution to the task. In business today, innovation is a leading competitive advantage and cross-functional teams promote innovation through a creative collaboration process. Members of a cross-functional team must be well versed in multi-tasking as they are simultaneously responsible for their cross-functional team duties as well as their normal day-to-day work tasks.
+
+### Common Goal
+
+* Better for the team , better for the individual
+
+* improve co-ordination and integration
+
+* work accross orgnisational boundaries
+
+* improve efficiency of the team by increasing productivity
+
+* Achieve customer satisfaction by working for the same goal
+
+Some researchers have viewed cross-functional interactions as cooperative or competitive in nature, while others have argued that organization’s functional areas are often forced to compete and cooperate simultaneously with one another (“coopetition”) and it is critical to understand how these complex relationships interplay and affect firm performance.
+
+### Cross Functional Team Skill Composition
+One common challenge of composing Cross Functional Teams is the thought that every technical member on the team is required to have all the technical skills necessary to perform any of the work. It helps that team members can perform more than one technical skill but it is still okay to have specialists. It is just best when not all members of the team are specialists.   
+
+#### More Information:
+
+* [17 PROVEN WAYS TO BENEFIT FROM A CROSS-FUNCTIONAL TEAM](https://www.scoro.com/blog/improve-cross-team-collaboration/)
+
+* [11 Reasons to Use Cross Functional Teams](https://blog.kainexus.com/employee-engagement/cross-functional-collaboration/cross-functional-teams/11-reasons)
+
+* [Cross-Functional Scrum Teams](https://www.scrumalliance.org/community/articles/2014/june/success-story-cross-functional-scrum-teams)
+
+* [Cross Functional Doesn’t Mean Everyone Can Do Everything](https://www.mountaingoatsoftware.com/blog/cross-functional-doesnt-mean-everyone-can-do-everything)
+
+* [Cross functional teams](https://dzone.com/articles/cross-functional-scrum-teams)

guide/english/agile/crystal/index.md

@@ -0,0 +1,31 @@
+---
+title: Crystal
+---
+## Crystal
+
+It is a methodology that is a very adaptable, lightweight approach to software development. It is a family of agile methodologies in which are included Crystal Clear, Crystal Yellow, Crystal Orange and others. Which of them has a unique attribute driven by many factors, like the size of the team, how critical the system is and the priorities of the project. Which states that each projects might need a different set of practices, rules, processes according to the project's unique characteristics.
+They were all developed by Alistair Cockburn in the 1990s. 
+
+According to him, the faces of the crystal are defined as Methodology, techniques and policies
+
+Methodology - elements which are part of the project
+Techniques - areas of skills
+Policies - organizationals do's and dont's
+
+Those methods are focused on:
+1. People
+2. Interaction
+3. Community
+4. Skills
+5. Talents
+6. Communications
+
+![Different Colors] https://upload.wikimedia.org/wikiversity/en/c/c5/Crystal_Family_example.jpg
+
+
+It takes different strokes to move the world, and according to Crystal, it takes different colors to move a project. 
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+
+[Wikiversity Article] https://en.wikiversity.org/wiki/Crystal_Methods

guide/english/agile/customer-units/index.md

@@ -0,0 +1,19 @@
+---
+title: Customer Units
+---
+## Customer Units
+
+In Agile, Customer units is a people and role that represent the voice, the expectation from customers/market targetted by a product. 
+
+Customer units responsible for user experience product, a vision of a product, road map of product, creating and maintaining product backlog, and anything.
+
+Example Person / Roles :
+->Product Managers
+->Sales 
+->Marketing 
+->End User 
+
+#### More Information:
+ Customer Unit : <a href="https://www.solutionsiq.com/agile-glossary/customer-unit/" target='_blank' rel='nofollow'>Solutions</a>
+
+

guide/english/agile/daily-standup-and-daily-scrum/index.md

@@ -0,0 +1,24 @@
+---
+title: Daily Stand-Up and Daily Scrum
+---
+## Daily Stand-Up and Daily Scrum
+
+The Daily Stand-Up (DSU) or Daily Scrum meeting is one of the integral parts of scrum methodology.
+
+As the name suggests, you hold the meeting daily, at the same time and, for a co-located team, in the same location. The meeting should be brief, finished in less than 15 minutes.
+
+Only members of the Development team are required to attend the Daily Stand-up. Typically, the Scrum Master and Product Owners will also attend, but they are not required.
+
+The standard agenda for each person is:
+* What have you done since the last DSU
+* What are you doing after this DSU
+* What are the major obstacles that are stopping your progress, and where do you need help
+
+Team members are to listen carefully to each other's contributions and attempt to identify areas where they can assist each other's progress. The standup meeting will also surface more lengthy topics of discussion that need to take place between different members of the team. These lengthier discussions that arise should then be halted and taken outside of the standup, involving only the relevant participants, and not the entire team. 
+
+### Example of Stand-up Meeting
+https://www.youtube.com/watch?v=_3VIC8u1UV8
+
+
+### More Information:
+Stand-up meeting: <a href="https://en.wikipedia.org/wiki/Stand-up_meeting" target='_blank' rel='nofollow'>Wikipedia</a>

guide/english/agile/delivery-team/index.md

@@ -0,0 +1,20 @@
+---
+title: Delivery Team
+---
+## Delivery Team
+
+A scrum team is made up of the Product Owner (PO), the Scrum Master (SM), and the Delivery Team.
+
+The delivery team is everyone but the PO and SM; the developers, testers, system analysts, database analysts, UI / UX analysts, and so on.
+
+For a scrum delivery team to be effective, it should be nimble (or agile!) enough for decisions to be agreed upon quickly while diverse enough so the vast majority of specalities required for software development can be covered by the entire team. Idealy, a team between 3 and 9 people generally works well for a scrum development team.
+
+The team must also foster mutual respect througout every member of the team. An effective scrum team will be able to share the workload and put the accomplishments of the team ahead of the accomplishments of the individual.
+
+<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds  -->
+
+#### More Information:
+Atlassian's primer article on Scrum [here.](https://www.atlassian.com/agile/scrum) 
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+
+

guide/english/agile/design-patterns/index.md

@@ -0,0 +1,30 @@
+---
+title: Design Patterns
+---
+## Design Patterns
+A design pattern is a common design solution to a common design problem. A collection of design patterns for a related field or domain is called a pattern language. Note that there are also patterns at other levels: code, concurrency, architecture, interaction design ...
+
+In software engineering, a software design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.
+
+Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Patterns that imply mutable state may be unsuited for functional programming languages, some patterns can be rendered unnecessary in languages that have built-in support for solving the problem they are trying to solve, and object-oriented patterns are not necessarily suitable for non-object-oriented languages.
+
+Design patterns may be viewed as a structured approach to computer programming intermediate between the levels of a programming paradigm and a concrete algorithm.
+
+The book that popularised the field is Gang of Four's (GoF) **Design Patterns: Elements of Reusable Object-Oriented Software** (1994). It present a series (23) of patterns for an conventional (C++) OO language classified in three types:
+* **Creational** (to create objects): abstract factory, builder, factory method, prototype, singleton.
+* **Structural** (to compose objects): adapter, bridge, composite, decorator, facade, flyweight, proxy.
+* **Behavioral** (to communicate between objects): chain of responsibility, command, interpreter, iterator, mediator, memmento, observer, state, strategy, template method, visitor.
+
+Patterns can be used for multiple objectives  (learning, communication, improving your tooling) but in agile they should be refactored from code with technical debt and not just added at the start (emergent design/architecture) as initially you don't have enough knowledge about the (future) system that is going to evolve. Note that what requires a pattern in a language or tool may not be needed or already be part of another language or tool. A framework is a set of cooperating classes that make up a reusable design for a specific type of software and are typically pattern-heavy.
+
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+- [Wikipedia on Design Patterns](https://en.wikipedia.org/wiki/Software_design_pattern)
+- [Wikipedia on GoF Book](https://en.wikipedia.org/wiki/Design_Patterns)
+- [Design Patterns by Source Making](https://sourcemaking.com/design_patterns): list of well known patterns available online
+- [Game Programming Patterns](http://gameprogrammingpatterns.com/): book about Design Patterns commonly used in Game Development, available to be read online for free
+- [Object Oriented Design](http://www.oodesign.com/)
+- [A Beginner’s Guide to Design Patterns](https://code.tutsplus.com/articles/a-beginners-guide-to-design-patterns--net-12752)
+- [From design patterns to category theory](http://blog.ploeh.dk/2017/10/04/from-design-patterns-to-category-theory/)
+

guide/english/agile/dsdm/index.md

@@ -0,0 +1,32 @@
+---
+title: DSDM
+---
+## DSDM
+
+DSDM stands for Dynamic Systems Development Method.  It is an Agile rapid development methodology, and aims to address the ongoing problem of the length of time it takes to develop information systems.  DSDM is more of a framework than a tightly-defined method, and much of the detail of how things should actually be done is left to the software development organisation or individual to decide.  DSDM adopts an incremental approach and uses the RAD (rapid application development) concept of timeboxing.  It also emphasizes the key role of people in the development process and is described as a user-centred approach.
+
+DSDM has 9 core principles, as follows:
+
+1) Active user involvement is imperative.
+2) Teams must be empowered to make decisions.  The four key variables of empowerment are: authority, resources, information, and accountability.
+3) Frequent delivery of products is essential.
+4) Fitness for business purpose is the essential criterion for acceptance of deliverables.
+5) Iterative and incremental development is necessary to converge on an accurate business solution.
+6) All changes during development are reversible (ie you do not proceed further down a particular path if problems are encountered; you backtrack to the last safe or agreed point, and then start down a new path).
+7) Requirements are baselined at a high level (ie the high-level business requirements, once agreed, are frozen).  This is essentially the scope of the project.
+8) Testing is integrated throughout the life cycle (ie test as you go rather than testing just at the end where it frequently gets squeezed).
+9) A collaborative and co-operative approach between all stakeholders is essential.
+
+The 5 main phases of the DSDM development cycle are:
+
+1) Feasibility study.
+2) Business study.
+3) Functional model iteration.
+4) System design and build iteration.
+5) Implementation.  
+
+#### More Information:
+You can read the following links to find out more.
+- <a href='https://www.agilebusiness.org/what-is-dsdm'> Agile Business - What is DSDM?
+- <a href='https://en.wikipedia.org/wiki/Dynamic_systems_development_method'> Wikipedia - Dynamic Systems Development Method
+

guide/english/agile/epics/index.md

@@ -0,0 +1,14 @@
+---
+title: Epics
+---
+## Epics
+An epic is a large user story that cannot be delivered as defined within a single iteration or is large enough that it can be split into smaller user stories. Epics usually cover a particular persona and give an overall idea of what is important to the user. An epic can be further broken down into various user stories that show individual tasks that a persona/user would like to perform.
+
+There is no standard form to represent epics. Some teams use the familiar user story formats (As A, I want, So That or In Order To, As A, I want) while other teams represent the epics with a short phrase.
+
+* While the stories that comprise an epic may be completed independently, their business value isn’t realized until the entire epic is complete
+
+### Epic Example
+In an application what helps freelance painters track their projects, a possible epic could be.
+
+Paul the Painter would like an easier way to manage his projects and provide his client with accurate changes and also bill them.

guide/english/agile/extreme-programming/index.md

@@ -0,0 +1,15 @@
+---
+title: Extreme Programming
+---
+## Extreme Programming
+
+Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements.<sup><a href='https://en.wikipedia.org/wiki/Extreme_programming' target='_blank' rel='nofollow'>1</a></sup>
+
+The basic advantage of XP is that the whole process is visible and accountable. The developers will make concrete commitments about what they will accomplish, show concrete progress in the form of deployable software, and when a milestone is reached they will describe exactly what they did and how and why that differed from the plan. This allows business-oriented people to make their own business commitments with confidence, to take advantage of opportunities as they arise, and eliminate dead-ends quickly and cheaply.<sup><a href='http://wiki.c2.com/?ExtremeProgramming' target='_blank' rel='nofollow'>2</a></sup> 
+-- Kent Beck
+
+<a target="_blank" title="By DonWells (Own work) [CC BY 3.0 (http://creativecommons.org/licenses/by/3.0)], via Wikimedia Commons" href="https://commons.wikimedia.org/wiki/File%3AXP-feedback.gif"><img width="256" alt="XP-feedback" src="https://upload.wikimedia.org/wikipedia/commons/4/44/XP-feedback.gif"/></a>
+
+#### More Information:
+
+<a href='http://www.extremeprogramming.org/rules.html' target='_blank' rel='nofollow'>Rules of Extreme Programming</a>

guide/english/agile/feature-based-planning/index.md

@@ -0,0 +1,15 @@
+---
+title: Feature Based Planning
+---
+## Feature Based Planning
+
+**Feature Based Planning** is a planning methodology that can be used to decide when to release software based on the features that will be delivered to the customers, rather than an arbitrary deadline based release.
+
+In this method of release planning, teams decide what feature/features should be prioritised. Based on the scope of these features the team can then predict when the next release can be deployed.
+
+
+
+#### More Information:
+[Feature-driven development](https://en.wikipedia.org/wiki/Feature-driven_development)
+
+

guide/english/agile/five-levels-of-agile-planning/index.md

@@ -0,0 +1,29 @@
+---
+title: Five Levels of Agile Planning
+---
+## Five Levels of Agile Planning
+
+A product owner needs to be familiar with the five levels of agile planning:
+  - Defining the product vision
+  - Defining the product roadmap
+  - Release planning
+  - Sprint planning
+  - Accounting for the outcome of daily scrums
+  
+Agile planning is always continuous and should be revised at least every three months.
+
+## Brief Synopsis of the Five Levels of Agile Planning
+
+ 1. Product Vision: What (Summary of the major benefits & features the product will provide), Who (Stakeholders), Why (Need & Opportunity), When (Project scheduling & time expectations), Constraints and Assumptions (impacts risk & cost).
+ 
+ 2. Product Roadmap: Releases - Date, Theme/Feature Set, Objective, Development Approach.
+ 
+ 3. Release Planning: Iteration, Team Capacity, Stories, Priority, Size, Estimates, Definition of Done.
+ 
+ 4. Sprint Planning: Stories - Tasks, Definition of Done, Level-of Effort, Commitment
+ 
+ 5. Daily Planning: What did I do yesterday? What will I do today? What is blocking me?
+
+#### More Information:
+
+<a href='https://www.scrumalliance.org/why-scrum/agile-atlas/agile-atlas-common-practices/planning/january-2014/five-levels-of-agile-planning' target='_blank' rel='nofollow'>Five Levels of Agile Planning</a>

guide/english/agile/functional-managers/index.md

@@ -0,0 +1,13 @@
+---
+title: Functional Managers
+---
+
+## Functional Managers
+
+A functional manager is a person that have management authority over group of people. That authority comes from the formal position of that person in the organization (eg. director of the department, quality department manager, development team manager). Role of functional managers is different then Project Managers or ScrumMasters and is not project based.  
+In more agile organizations different models exists. Functional manager often are responsible for developing people in their groups, securing budgets and time for people. 
+However there are also some Agile company models where functions usually assigned to functional managers are distributed to other roles within organization (eg. Spotify model with Tribes, Guilds, Chapters, Squads).
+
+Out in the traditional world of work companies organize people into a hierarchy. People with similar work roles are grouped into functional areas and led by a Functional Manager. The functional manager is generally responsible for the guidance and well-being of the employees who report directly to her.
+
+Agile project teams will often work with functional managers who control the resources the team needs to get work done. An example would be working with a functional manager in procurement to assign a person to work with the team to procure software licenses. 

guide/english/agile/index.md

@@ -0,0 +1,26 @@
+---
+title: Agile
+---
+## Agile
+
+Agile software development is a collection of methodologies used to manage teams of developers. It advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. People and communication are considered more important than tools and processes.
+
+Agile emphasizes asking end users what they want, and frequently showing them demos of the product as it is developed. This stands in contrast to the "Waterfall" approach, specification-driven development, and what Agile practitioners call "Big Up-Front Design." In these approaches, the features are planned out and budgeted before development starts. 
+
+With Agile, the emphasis is on "agility" - being able to quickly respond to feedback from users and other changing circumstances.
+
+![A comic from Commitstrip.com showing a product manager explaining to a developer that they are switching to agile, but then asking the developer to plan everything up front](https://www.commitstrip.com/wp-content/uploads/2017/01/Strip-Budegt-fixe-pour-projet-flexible-english650-final.jpg)
+
+The agile software development places its emphasis on four core values.
+1. Preference on team and individual interactions over tools and processes.
+2. A working software over exhaustive documentation.
+3. Collaboration with customer is given more importance than contract negotiations.
+4. Response to changes over following a plan.
+
+There are many different flavors of agile, including Scrum and Extreme Programming.
+
+![Various methods present in Agile testing or Agile Testing Methodologies](https://www.guru99.com/images/11-2014/agile_Processesv1_2.png)
+
+### More information
+
+[Agile Alliance's Homepage](https://www.agilealliance.org/)

guide/english/agile/integration-hell/index.md

@@ -0,0 +1,20 @@
+---
+title: Integration Hell
+---
+## Integration Hell
+
+Integration Hell is a slang term for when all the members of a development team goes through the process of implementing their code at random times with no way to incorporate the different pieces of code into one seamless sring of code. The development team will have to spend several hours or days testing and tweaking the code to get it all to work.
+
+In practice, the longer components are developed in isolation, the more the interfaces tend to diverge from what is expected. When the components are finally integrated at the end of the project, it would take a great deal more time than allocated, often leading to deadline pressures, and difficult integration. This painful integration work at the end of the project is the eponymous hell.
+
+Continuous Integration, the idea that a development team should use specific tools to "continously integrate" the parts of the code they are working on multiple times a day so that the tools can match the different "chunks" of code together to integrate much more seamlessly than before.
+
+Code Repositories, like Git (and it's open source interface we all know and love, GitHub) allow development teams to organize their efforts so that more time can be spent coding and less time on worrying if the different parts of the code will all integrate.
+
+<a href='https://guide.freecodecamp.org/agile/continuous-integration/'>Continuous Integration</a> is the Agile antidote to this problem. Integration is still painful, but doing it at least daily keeps interfaces from diverging too much.
+
+#### More Information:
+- <a href='https://tobeagile.com/2017/03/08/avoiding-integration-hell/'>Avoiding Integration Hell</a>
+- <a href='http://wiki.c2.com/?IntegrationHell'>Integration Hell</a>
+- <a href='https://www.apicasystems.com/blog/top-5-tips-avoid-integration-hell-continuous-integration/'>Top 5 Tips to Avoid “Integration Hell” with Continuous Integration</a>
+- <a href="https://dzone.com/articles/continuous-integration-how-0">D-Zone article on Integration Hell and how Continous Integration has help make it almost a thing of the past</a>

guide/english/agile/invest/index.md

@@ -0,0 +1,34 @@
+---
+title: INVEST
+---
+## INVEST
+
+**I** | **independent**
+----- | -----  
+**N** | **negotiable**
+**V** | **valuable**
+**E** | **estimable**
+**S** | **small**
+**T** | **testable**
+
+When you are refining and sizing the User Stories in the backlog, the INVEST mnemonic can help you determine if they are ready
+
+- Independent
+  - The story is as distinct as possible from the other stories. Avoid "2-stories in one".
+- Negotiable
+  - As a part of the conversation between the Product Owner and the Delivery Team during grooming, the details for the story can be discussed, refined, and improved. The acceptance criteria can be adjusted based on the ebb and flow of customer need and technical capability.
+- Valuable
+  - There is a value to the customer. Money earned, time saved, efficiency gained, loss stopped, etc. by the implementation of the story.
+- Estimable
+  - During grooming, the description and conversation for the story have addressed enough of the questions from the Delivery Team that they can confidently and comfortably Size the story.
+- Small
+  - You can complete the story within the established iteration.
+- Testable
+  - The story includes acceptance criteria you will use to confirm that the code meets the customer's needs.
+
+<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds  -->
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+<a href='https://www.google.com/search?q=agile+invest+negotiable&ie=utf-8&oe=utf-8' target='_blank' rel='nofollow'>Lots on Google</a>
+

guide/english/agile/kano-analysis/index.md

@@ -0,0 +1,15 @@
+---
+title: Kano Analysis
+---
+## Kano Analysis
+
+This is a stub. <a href='https://github.com/freecodecamp/guides/tree/master/src/pages/agile/kano-analysis/index.md' target='_blank' rel='nofollow'>Help our community expand it</a>.
+
+<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
+
+<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds  -->
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+
+

guide/english/agile/lean-software-development/index.md

@@ -0,0 +1,35 @@
+---
+title: Lean Software Development
+---
+## Lean Software Development
+
+### Introduction
+
+Lean Software Development is the process of building software with the focus on using techniques which minimize extra work and wasted effort. These techniques are borrowed from the Lean manufacturing movement and applied to the context of software development.
+
+### Key Concepts
+
+There are seven principles within the methodology which include:
+  1. Eliminate waste
+  2. Amplify learning
+  3. Decide as late as possible
+  4. Deliver as fast as possible
+  5. Empower the team
+  6. Build integrity in
+  7. See the whole
+
+### Metaphors
+
+The act of programming is viewed as an assembly line, where every feature or bug fix is called a "change request". This assembly line of "change requests" can then be considered as a "value stream" with the goal being to minimize the time that each "change request" is on the line prior to being delivered.
+
+Software which is not yet delivered is considered as "inventory" since it has not yet provided value to the company or the customer. This includes any software which is partially complete. Therefore to maximize throughput it is important to deliver many small complete working pieces of software.
+
+In order to minimize the "inventory" it is important to secede control to the "workers" who would be the software developers, as they would be best equipped to create automated processes to "mistake proof" the various parts of the assembly line.
+
+### References
+
+The original source of written documentation on the Lean techniques is the book Lean Software Development, An Agile Toolkit by Mary and Tom Poppendieck.
+
+Additional books by the author(s) include:
+  - Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck
+  - Leading Lean Software Development: Results Are not the Point by Mary Poppendieck

guide/english/agile/meta-scrum/index.md

@@ -0,0 +1,22 @@
+---
+title: Meta Scrum
+---
+## Meta Scrum
+
+This is a stub. <a href='https://github.com/freecodecamp/guides/tree/master/src/pages/agile/meta-scrum/index.md' target='_blank' rel='nofollow'>Help our community expand it</a>.
+
+<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
+
+<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds  -->
+
+A Meta Scrum is a virtual team composed of Product Owners from other scrum teams that are working on different aspects of a larger project. The Product Owners will coordinate Epics, product releases, and product lines. The Meta Scrum can also include company leadership and other key Stakeholders.
+
+The Product Owners that make up the Meta Scrum coordinate Epics and other items in the backlog created by the EAT. They can also work to eliminate impediments that individual scrum masters cannot resolve.
+
+The Meta Scrum aligns priorities across teams by establishing a standardized, recurring forum for communication among teams. Stakeholders and Product Owners should use this virtual team to express preferences and establish product scope/vision rather than approaching individual teams.
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+ - <a href=“https://www.solutionsiq.com/agile-glossary/meta-scrum/”>https://www.solutionsiq.com/agile-glossary/meta-scrum/</a>
+ - <a href=“https://agileparkinglot.blog/2010/02/25/what-is-metascrum/“>https://agileparkinglot.blog/2010/02/25/what-is-metascrum/</a>
+

guide/english/agile/minimum-marketable-features/index.md

@@ -0,0 +1,27 @@
+---
+title: Minimum Marketable Features
+---
+## Minimum Marketable Features
+
+A Minimum Marketable Feature (MMF) is a self-contained feature that can be developed quickly and gives significant value to the user. 
+
+**It is important to note:** Minimum Marketable Feature is not the same as the Minimum Viable Product (MVP). They are different concepts. However, both are essential to supporting the idea that Developers should strive for minimum functionality in order to accomplish any given outcome.
+
+Break down MMF to its core components:
+
+**Minimum** - The absolute smallest set of functionality. This is essential for getting any given feature to market quickly.
+
+**Marketable** - Selling the end user or organization that the feature has significant value.
+
+**Feature** - The percieved value by the end user. What does it give me? Brand recognition? More Revenue? Help cut costs? Does it give me a competative advantage? 
+
+<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
+
+<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds  -->
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+
+### Sources
+<sup>1.</sup> [https://www.agilealliance.org/glossary/mmf/ Accessed: October 25, 2017](https://www.agilealliance.org/glossary/mmf/)
+<sup>2.</sup> [https://www.prokarma.com/blog/2015/10/23/minimum-marketable-features-agile-essential Accessed: October 25, 2017](https://www.prokarma.com/blog/2015/10/23/minimum-marketable-features-agile-essential)

guide/english/agile/minimum-viable-product/index.md

@@ -0,0 +1,14 @@
+---
+title: Minimum Viable Product
+---
+## Minimum Viable Product
+The idea is to rapidly build a minimum set of features that is enough to deploy the product and test key assumptions about customers’ interactions with the product.  
+
+#### A Minimum Viable Product has three key characteristics:
+- It has enough value that people are willing to use it or buy it initially.
+- It demonstrates enough future benefit to retain early adopters.
+- It provides a feedback loop to guide future development.
+
+Learn more about MVP:
+<a href='https://youtu.be/MHJn_SubN4E' target='_blank' rel='nofollow'>what is a mvp?</a>
+

guide/english/agile/moscow/index.md

@@ -0,0 +1,44 @@
+---
+title: Moscow
+---
+## Moscow 
+
+## MoSCoW Method
+
+One of the meaning of this word is the MoSCoW method - a prioritization technique used in management, business analysis, project management, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement - also known as MoSCoW prioritization or MoSCoW analysis.
+
+## Prioritization of MoSCoW requirements
+
+All requirements are important, but they are prioritized to deliver the greatest and most immediate business benefits early. Developers will initially try to deliver all the Must have, Should have and Could have requirements but the Should and Could requirements will be the first to be removed if the delivery timescale looks threatened.
+
+The plain English meaning of the prioritization categories has value in getting customers to better understand the impact of setting a priority, compared to alternatives like High, Medium and Low.
+
+The categories are typically understood as:
+
+## Must have
+    Requirements labeled as Must have are critical to the current delivery timebox in order for it to be a success. If even one Must have requirement is not included, the project delivery should be considered a failure. MUST can also be considered an acronym for the Minimum Usable SubseT.
+
+## Should have
+    Requirements labeled as Should have are important but not necessary for delivery in the current delivery timebox. While Should have requirements can be as important as Must have, they are often not as time-critical or there may be another way to satisfy the requirement, so that it can be held back until a future delivery timebox.
+
+## Could have
+    Requirements labeled as Could have are desirable but not necessary, and could improve user experience or customer satisfaction for little development cost. These will typically be included if time and resources permit.
+
+## Won't have
+    Requirements labeled as Won't have have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, Won't have requirements are not planned into the schedule for the next delivery timebox. Won't have requirements are either dropped or reconsidered for inclusion in a later timebox. 
+
+MoSCoW is a coarse-grain method to prioritise (categorise) Product Backlog Items (or requirements, use cases, user stories ... depending on the methodology used).
+MoSCoW is often used with timeboxing, where a deadline is fixed so that the focus must be on the most important requirements. 
+The term MoSCoW itself is an acronym derived from the first letter of each of four prioritization categories (Must have, Should have, Could have, and Won't have):
+
+* **Must have**: Critical to the current delivery timebox in order for it to be a success. It is typically part of the MVP (Minimum Viable Product).
+* **Should have**: Important but not necessary for delivery in the current delivery timebox. 
+* **Could have**: Desirable but not necessary, an improvement.
+* **Won't have**: Least-critical, lowest-payback items, or not appropriate at this time.
+
+By prioritizing in this way, a common definition of the project can be reached and stakeholders' expectations set accordingly. Note That MoSCoW is a bit lax about how to distinguish the category of an item and when something will be done, if not in this timebox.
+
+#### More Information:
+
+[Wikipedia](https://en.wikipedia.org/wiki/MoSCoW_method)
+

guide/english/agile/nonfunctional-requirements/index.md

@@ -0,0 +1,26 @@
+---
+title: Nonfunctional Requirements
+---
+## Nonfunctional Requirements
+
+A non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors (a functional requirement). Non-functional requirements are often called "quality attributes", "constraints" or "non-behavioral requirements". 
+
+Informally, these are sometimes called the "ilities", from attributes like stability and portability. NFRs can be divided into two main categories:
+* **Execution qualities**, such as safety, security and usability, which are observable during operation (at run time).
+* **Evolution qualities**, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the system
+
+Usually you can refine a non-functional requirement into a set of functional requirements as a way of detailing and allowing (partial) testing and validation.
+
+### Examples:
+
+* The printer should print 5 seconds after the button is pressed
+* The code should be written in Java
+* The UI should be easily navigable
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+* [Wikipedia article](https://en.wikipedia.org/wiki/Non-functional_requirement)
+* [ReQtest](http://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/) Explains the difference between functional and nonfunctional requirements
+* [Scaled Agile](http://www.scaledagileframework.com/nonfunctional-requirements/) Works through the process from finding to testing nonfunctional requirements
+
+

guide/english/agile/osmotic-communications/index.md

@@ -0,0 +1,11 @@
+---
+title: Osmotic Communications
+---
+## Osmotic Communications
+**Osmotic Communications** is one of the important factors of a successful agile project.  
+
+In agile project, team members usually co-located, any discussion among some of the team members will flow to other team members. They can then pick up relevant information and join in discussion wherever necessary.  
+
+#### More Information:
+https://www.projectmanagement.com/wikis/295442/Osmotic-Communications
+http://agilemodeling.com/essays/communication.htm

guide/english/agile/pair-programming/index.md

@@ -0,0 +1,12 @@
+---
+title: Pair Programming
+---
+## Pair Programming
+
+Extreme Programming (XP) recommends that all production code be written by two programmers working at the same time at the same computer, taking turns on the keyboard. Several academic studies have demonstrated that pair programming results in fewer bugs and more maintainable software. Pair programming can also help spread knowledge within the team, contributing to a larger <a href='http://deviq.com/bus-factor/' target='_blank' rel='nofollow'>Bus Factor</a> and helping to promote <a href='http://deviq.com/collective-code-ownership/' target='_blank' rel='nofollow'>Collective Code Ownership</a>.
+
+#### More Information:
+
+- <a href='http://bit.ly/PS-PairProgramming' target='_blank' rel='nofollow'>Pair Programming Fundamentals (training course)</a>
+- <a href='https://www.versionone.com/agile-101/agile-software-programming-best-practices/pair-programming/' target='_blank' rel='nofollow'>Agile Software Programming Best Practices</a>
+

guide/english/agile/parallel-development/index.md

@@ -0,0 +1,13 @@
+---
+title: Parallel Development
+---
+## Parallel Development
+
+Parallel Development stands for the development process separated into multiple branches, to provide a versatile product with stable releases and new features. In a more common straightforward software development process you have only one branch with bug fixes and improvements, alongside with new features. In parallel development multiple branches can coexist.
+
+Usually parallel development contains a main, "master" branch which is the most stable and contains important fixes for existing code. From the main branch, more branches are created to add new "paths" to the existing code. These branches provide new features, but do not include fixes, applied in the mean time from the master branch. Clients know about these releases and have special equipment, or test machines to be able to test the new features. When QA tests are passed, side branch can be merged with the main branch to introduce new features to the release version.
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+
+

guide/english/agile/pirate-metrics/index.md

@@ -0,0 +1,24 @@
+---
+title: Pirate Metrics
+---
+## Pirate Metrics
+
+Dave McClure identified five high-level metric categories critical to a startup’s success: 
+Acquisition, Activation, Retention, Revenue, Referral. 
+
+He coined the term “Pirate Metrics” from the acronym for these five metric categories (AARRR).
+
+In their book Lean Analytics, Croll and Yoskovitz interpret these metrics visually as a funnel:
+![Lean Analytics Figure 5.1](https://github.com/yunChigewan/storage/blob/master/figure_5_1.jpg?raw=true)
+Lean Analytics, 2013 
+
+
+And with more pointed explanations as a table:
+![Lean Analytics Table 5.1](https://github.com/yunChigewan/storage/blob/master/table_5_1.jpg?raw=true)
+Lean Analytics, 2013
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+- Original Pirate Metrics Slideshow (McClure) https://www.slideshare.net/dmc500hats/startup-metrics-for-pirates-long-version
+- Lean Analytics Book Website http://leananalyticsbook.com/
+- Notion has a really good guide on Pirate Metrics (including Team measures) on their [website](http://usenotion.com/aarrrt/)

guide/english/agile/planning-poker/index.md

@@ -0,0 +1,34 @@
+---
+title: Planning Poker
+---
+## Planning Poker
+
+### Introduction
+Planning poker is an estimation and planning technique in the Agile development model. It is used to estimate the development effort  required for a [user story](../user-stories/index.md) or a feature. 
+
+### Process
+The planning poker is done for one user story at a time.
+
+Each estimator holds an identical set of poker cards consisting of cards with various values. The card values are usually from the Fibonacci Sequence. The unit used for the values can be the number of days, story points, or any other kind of estimation unit agreed on by the team.
+
+The product owner (PO) or stakeholder explains the story that is to be estimated.
+
+The team discusses the story, asking any clarifying questions that they might have. This helps the team get a better understanding on *what* the PO wants. 
+
+At the end of the discussion, each person first selects a card (representing their estimate for the story) without showing it to the others. Then, they reveal their cards at the same time.
+
+If all the cards have the same value, the value becomes the estimate for the story. If there are differences, the team discusses the reasons for the values that they have chosen. It is of high value that the team members who gave the lowest and highest estimates provide justifications for their estimates. 
+
+After this discussion, the process of picking a card in private and then revealing it at the same time is repeated. This is done until there is a consensus on the estimate.
+
+Because planning poker is a tool to moderate a *joint* expert estimation, it leads to a better common understanding and perhaps even refinement of the feature request. It is of high value even when the team is operating in a No-Estimates mode. 
+
+A moderator should try to avoid confirmation bias. 
+
+Things worth mentioning:
+- Estimations are not comparable between teams, as every team has its own scala.
+- Estimations should include everything that needs to be done in order for a piece of work to be done: designing, coding, testing, communicating, code reviews (+ all possible risks)
+- The value of using planning poker is in the resulting discussions, as they reveal different views on a possible implementation
+
+### More Information:
+- Planning poker video: <a href='https://www.youtube.com/watch?v=MrIZMuvjTws' target='_blank' rel='nofollow'>YouTube</a>

guide/english/agile/product-management/index.md

@@ -0,0 +1,52 @@
+---
+title: Product Management
+---
+## Product Management
+
+Product Management is an organisational function that assumes responsibility for the entire lifecycle of the products that are being sold. As a business function, Product Management, is held accountable for creating customer value and measurable benefits to the business. 
+
+There are a few core responsibilities common to most product management roles inside both established enterprise companies and at startups. Most often product management is responsible for understanding customer requirements, defining and prioritizing them, and working with the engineering team to build them. Setting strategy and defining the roadmap is often considered to be inbound work and bringing the product to market is often considered to be "outbound."
+
+It is important to understand the differences between inbound and outbound product management because a great product manager has the diverse set of skills to do both well. 
+
+Difference between Product Management and Project Management is, the scale and life cycle. Project Managers ensure multiple products/services/projects are delivered to a customer, while Product Managers go beyond development and work towards longjevity and operation of a product/service.
+
+In Game development we can see the clear shift from Projects to Products due to games having more detailed post launch plans and monetization strategies.
+
+### Inbound Product Management
+
+Inbound product management involves gathering customer research, competitive intelligence, and industry trends as well as setting strategy and managing the product roadmap.
+
+Product Strategy and Definition (Inbound)
+
+- Strategy and vision
+- Customer interviews
+- Defining features and requirements
+- Building roadmaps
+- Release management
+- Go-to-resource for engineering
+- Sales and support training
+
+### Outbound Product Management
+
+Outbound product management involve product marketing responsibilities such as: messaging and branding, customer communication, new product launches, advertising, PR, and events. Depending on the organization these roles can be performed by the same person or two different people or groups that work closely together.
+
+Product Marketing and Go-to-Market (Outbound)
+
+- Competitive differentiation
+- Positioning and messaging
+- Naming and branding
+- Customer communication
+- Product launches
+- Press and analyst relations
+
+### Product Manager
+
+Product management continues to expand as a profession. Demand for qualified product managers is growing at every level. There are a variety of roles and responsibilities depending on experience level. Opportunities range from an Associate Product Manager all the way to CPO.
+
+Most Product Managers have been in different roles earlier in their careers. Very often software engineers, sales engineers or professional services consultant grow into the role of Product Manager. But in some companies (e.g. Google, Facebook, ...), junior Product Managers are recruited straight out of school, supported by career programs to teach them on the job.   
+
+#### More Information:
+Wikipedia page: https://en.wikipedia.org/wiki/Product_management
+
+

guide/english/agile/product-owners/index.md

@@ -0,0 +1,33 @@
+---
+title: Product Owners
+---
+## Product Owners
+
+Product Owners lead the product vision and release planning. They are in charge of defining the features, the release date, and the content that makes up a shippable product. The goal of a Product Owner is to build the right thing quickly and correctly.
+
+At a high-level, the Product Owner is responsible for the following:
+
+* Owner of the product vision
+* Leads release planning
+* Defines features and content of the release
+* Manages team's understanding of the release
+* Creates and curates the product backlog
+* Prioritizes the product backlog
+* Guides team through the release cycle
+* Makes trade-off decisions
+* Accepts or rejections work
+
+The Product Owner creates a backlog of items that they think would make a good product. This knowledge is based on their understanding of the market, user testing, and market projection. Product Owners adjust the long-term goals of the product based on the feedback they receive from users and stakeholders. They also act as the point of contact with stakeholders and manage scope and expectations. 
+
+Once the Product Owner has received feedback from the various stakeholders, they then refine the backlog to add as much detail as possible in order to create a Minimum Viable Product (MVP)for that release.
+
+The Product Owner then prioritizes the workload to ensure that the stories that are completed address both business value and user goals. Also, if there are risks associated with certain stories, the Product Owner puts those at the top of the backlog so that the risks are addressed early.
+
+Working with the team and the Scrum Master, the Product owner attends sprint planning meetings to loop groomed stories into the sprint. Throughout the sprint, the Product Owner ensures that the team completes the work according to the Definition of Done (DoD), answers any questions that may arise, and update stakeholders. 
+
+When the sprint is complete, the Product Owner participates in the Sprint Review along with other stakeholders. Making sure that each story meets the DoD, the Product Owner prepares for the next sprint by gathering feedback and prioritizing work based on what was completed. 
+
+
+### More Information:
+- Agile Product Ownership in a Nutshell video: [YouTube](https://www.youtube.com/watch?v=502ILHjX9EE)
+

guide/english/agile/rapid-application-development/index.md

@@ -0,0 +1,22 @@
+---
+title: Rapid Application Development
+---
+## Rapid Application Development
+
+Rapid Application Development (RAD) was devised as a reaction to the problems of traditional software development methodologies, particularly the problems of long development lead times.  It also addresses the problems associated with changing requirements during the development process.  
+
+The main principles of RAD are as follows:
+1) Incremental development. This is the main means by which RAD handles changing requirements.  Some requirements will only emerge when the users see and experience the system in use. Requirements are never seen as complete - they evolve over time due to changing circumstances.  The RAD process starts with a high-level, non-specific list of requirements which are refined during the development process.
+2) Timeboxing.  With timeboxing, the system is divided up into a number of components or timeboxes that are developed separately. The most important requirements are developed in the first timebox. Features are delivered quickly and often.
+3) The Pareto principle. Also known as the 80/20 rule, this means that around 80% of a system's functionality can be delivered with around 20% of the total effort needed. Therefore, the last (and most complex) 20% of requirements take the most effort and time to deliver. So, you should choose as much of the 80% to deliver as possible within the first few timeboxes.  The rest, if it proves necessary, can be delivered in subsequent timeboxes.
+4) MoSCoW rules. MoSCoW is a method used for prioritising work items in software development. Items are ranked as Must Have, Should Have, Could Have or Would Like to Have. Must Have items are those which must be included in a product for it to be accepted into release, with the other classifications in descending priority.
+5) JAD workshops. Joint Application Development (JAD) is a facilitated meeting where requirements gathering is carried out, in particular interviewing users of the system to be developed. The JAD workshop usually takes place early on in the development process, although additional meetings can be organised if required later in the process.
+6) Prototyping. Building a prototype helps to establish and clarify the user requirements, and in some cases it evolves to become the system itself.
+7) Sponsor and champion. An executive sponsor is someone within the organisation who wants the system, is committed to achieving it and is prepared to fund it. A champion is someone, usually at a lower level of seniority than an executive, who is committed to the project and is prepared to drive it forward to completion.
+8) Toolsets. RAD usually adopts toolsets as a means of speeding up the development process and improving productivity. Tools are available for change control, configuration management and code reuse.
+
+#### More Information:
+- https://en.wikipedia.org/wiki/Rapid_application_development - Wikipedia article on RAD
+- https://www.tutorialspoint.com/sdlc/sdlc_rad_model.htm - TutorialsPoint tutorial on RAD
+
+

guide/english/agile/rational-unified-process/index.md

@@ -0,0 +1,15 @@
+---
+title: Rational Unified Process
+---
+## Rational Unified Process
+
+This is a stub. <a href='https://github.com/freecodecamp/guides/tree/master/src/pages/agile/rational-unified-process/index.md' target='_blank' rel='nofollow'>Help our community expand it</a>.
+
+<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
+
+<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds  -->
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+
+

guide/english/agile/release-planning/index.md

@@ -0,0 +1,15 @@
+---
+title: Release Planning
+---
+## Release Planning
+
+This is a stub. <a href='https://github.com/freecodecamp/guides/tree/master/src/pages/agile/release-planning/index.md' target='_blank' rel='nofollow'>Help our community expand it</a>.
+
+<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
+
+<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds  -->
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+
+

guide/english/agile/release-trains/index.md

@@ -0,0 +1,20 @@
+---
+title: Release Trains
+---
+## Release Trains
+
+The Release Train (also known as the Agile Release Train or ART) is a long-lived team of Agile teams, which, along with other stakeholders, develops and delivers solutions incrementally, using a series of fixed-length Iterations within a Program Increment (PI) timebox. The ART aligns teams to a common business and technology mission.
+
+## Details
+
+ARTs are cross-functional and have all the capabilities—software, hardware, firmware, and other—needed to define, implement, test, and deploy new system functionality. An ART operates with a goal of achieving a continuous flow of value.
+
+ARTs include the teams that define, build, and test features and components. SAFe teams have a choice of Agile practices, based primarily on Scrum, XP, and Kanban. Software quality practices include continuous integration, test-first, refactoring, pair work, and collective ownership. Hardware quality is supported by exploratory early iterations, frequent system-level integration, design verification, modeling, and Set-Based Design. 
+
+Agile architecture supports software and hardware quality. Each Agile team has five to nine dedicated individual contributors, covering all the roles necessary to build a quality increment of value for an iteration. Teams can deliver software, hardware, and any combination. And of course, Agile teams within the ART are themselves cross-functional.
+
+<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds  -->
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+<a href='http://www.scaledagileframework.com/agile-release-train/' target='_blank' rel='nofollow'>Scaled Agile</a>.

guide/english/agile/retrospectives/index.md

@@ -0,0 +1,45 @@
+---
+title: Retrospectives
+---
+
+## Retrospectives
+
+The Sprint Retrospective can really be the most useful and important of the scrum ceremonies.
+
+The concept of *"Inspect and Adapt"* is crucial to creating a successful and thriving team.
+
+The standard agenda for the retrospective is:
+
+* What do we keep doing?
+* What do we stop doing?
+* What do we start doing?
+* Who do we want to say thank you to? (Not necessary but good practice)
+
+And from this discussion, the team creates a list of behaviors that they work on, collectively, over time. 
+
+When commiting to action items, make sure you focus on 1 - 3. It is better to get a couple done, than commiting to more and not doing them. If it is difficult to come up with actions, try running experiments: Write down what you will do and what you want to achieve with that. In the following retro check if what you did achieved what you had planned. If it did not - you can learn out of the experiment and try out something else. 
+
+A good approach to find out which topics should be discussed is *"Discuss and mention"*. It consists on a board with as many columns as people in the team (you can use something like Trello or just a regular whiteboard) and two more for the things to "discuss" and those to be "mentioned". Everybody has 10 minutes to fill their column with things from the last sprint they want to highlight (these are represented with cards or Post-it's). Afterwards, each team member explains each of their own items. Finally, each team member chooses which topics they think should be mentioned or discussed, by moving the card/post-it to the respectively column. The team then decides which topics should be discussed and talk about them for about 10 minutes.
+
+Invite the scrum team only to the Retrospective. (Delivery Team, Product Owner, Scrum Master). Discourage managers, stakeholders, business partners, etc. They are a distraction and can hinder the sense of openness the team needs.
+
+When conducting a retrospective make sure that in the first 5 - 10 minutes everyone says at least a couple of words. When team members speak up in the beginning of the meeting, it is more likely that they contribute during the whole meeting.
+
+During the retrospective it is important that the team stays productive. A simple way to keep people in a positive mood is to focus on what is in the control of the team.
+
+- For a co-located team, index cards and post-its work great for this process.
+- For distributed teams, there are a variety of online tools and apps to facilitate the discussion
+  - https://www.senseitool.com/home
+  - http://www.leancoffeetable.com/
+
+Action items should be notated on a board to make tracking progress visual and more distinguishable. Every new retrospective should start with reviewing the status of the action items decided upon during the *previous* restrospective.
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+
+- Inspirations for preparing a retrospective:
+  - https://plans-for-retrospectives.com/en/
+  - http://www.funretrospectives.com/
+- How to run experiments with the popcorn flow:
+  - https://www.slideshare.net/cperrone/popcornflow-continuous-evolution-through-ultrarapid-experimentation
+

guide/english/agile/safe/index.md

@@ -0,0 +1,38 @@
+---
+title: SAFe
+---
+## SAFe
+
+SAFe stands for "Scaled Agile Framework" and is an agile software development framework that is designed for large-scale agile development involving many teams.
+
+The main website (<a target='_blank' rel='nofollow' href="http://www.scaledagileframework.com/">http://www.scaledagileframework.com/</a>) is an freely available online knowledge base on implementing SAFe.
+
+## Principles
+
+There are nine, underlying principles for SAFe
+
+1. **Take an economic view** - evaluate economic costs of decisions, developments, and risks
+2. **Apply systems thinking** - development processes are interactions among the systems used by workers and thus need to view progress with systems thinking
+3. **Assume variability; preserve options** - requirements change, be flexible, and use empirical data to narrow focus
+4. **Build incrementally with fast, integrated learning cycles** - fast, incremental builds allow rapid feedback in order to change the project if necessary
+5. **Base milestones on objective evaluation on working systems** - objective evaluation provides important information such as financials and governance as feedback
+6. **Visualize and limit WIP, reduce batch sizes, and manage queue lengths** - do these to achieve continuous flow to move quickly and visualize progress; WIP = work-in-progress
+7. **Apply cadence, synchronize with cross-domain planning** - cadence is setting dates when certain events happen (e.g. release weekly) and synchronizing makes sure everyone has the same goals in mind
+8. **Unlock the intrinsic motivation of knowledge workers** - people work better when you make use of their personal motivations
+9. **Decentralize decision-making** - allows faster action, which may be not the best solution, but allows faster communication among teams; centralized decision-making may be necessary for more strategic or global decisions
+
+## Configurations
+
+There are four variations of SAFe, varying in complexity and needs of your project:
+
+1. Essential SAFe
+2. Portfolio SAFe
+3. Large Solution SAFe
+4. Full SAFe
+
+#### More Information:
+
+- <a href="https://en.wikipedia.org/wiki/Scaled_Agile_Framework" target="_blank" rel="nofollow">Scaled Agile Framework</a>
+- <a href="http://www.scaledagileframework.com/what-is-safe/" target="_blank" rel="nofollow">What is SAFe?</a>
+- <a href="http://www.scaledagileframework.com/essential-safe/" target="_blank" rel="nofollow">The Ten Essential Elements</a>
+- <a href="http://www.scaledagileframework.com/safe-lean-agile-principles/" target="_blank" rel="nofollow">SAFe Principles</a>

guide/english/agile/scrum/index.md

@@ -0,0 +1,44 @@
+---
+title: Scrum
+---
+## Scrum
+
+Scrum is one of the methodologies under the Agile umbrella. The name is derived from a method of resuming play in the sport of rugby, in which the entire team moves together to make ground. Similarly, a scrum in Agile involves all parts of the team working on the same set of goals. In the scrum method, a prioritized list of tasks is presented to the team, and over the course of a "sprint" (usually two weeks), those tasks are completed, in order, by the team. This insures that the highest-priority tasks or deliverables are completed before time or funds run out. 
+
+### Components of a Scrum
+
+Scrum is one of the methodologies under the Agile umbrella. It originates from 'scrummage' which is a term used in rugby to denote players huddling together to get possession of the ball.
+The practice revolves around 
+
+- A set of roles (delivery team, product owner, and scrum master)
+- Ceremonies (sprint planning, daily standup, sprint review, sprint retrospective, and backlog grooming)
+- Artifacts (product backlog, sprint backlog, product increment, and info radiators and reports).
+- The main goal is to keep the team aligned on project progress to facilitate rapid iteration.
+- Many organisations have opted for Scrum, because unlike the Waterfall model, it ensures a deliverable at the end of each Sprint.
+
+## Artifacts
+- Sprint: It is the time duration, mostly in weeks, for which a Team works to achieve or create a deliverable. A deliverable can defined as a piece of code of fragment of the Final Product which the team wants o achieve. Scrum advises to keep the duration of a Sprint between 2-4 weeks.
+- Product Backlog: It is the list of tasks a Team is supposed to finish within the current Sprint. It is decided by the Product Owner, in agreement with the Management as well as Delivery Team.
+
+## Roles
+- Product Owner(PO): The ONLY Accountable person to the Management. PO decides what goes in or out of the Product Backlog.
+- Delivery Team: They are required to work in accordance with the tasks set by their PO in the product backlog and deliver the required delivarable at the end of the sprint.
+- Scrum Masters: - Scrum Master's has to strictly adhere to Scrum Guide and make the team understand the need to adhere to Scrum guide when following Scrum. It is a Scrum Master's job to ensure all Scrum ceremonies being conducted on time and participated by all the required people as per the scrum guide. The SM has to ensure that the Daily Scrum is conducted regularly and actively participated by the team.
+
+#### More Information:
+
+There are several online tools that can be used to do scrum for your team:
+
+- [Scrum Do](https://www.scrumdo.com/) 
+- [Asana](http://www.asana.com)
+- [Trello](http://trello.com)
+- [Monday](https://monday.com)
+- [Basecamp](https://basecamp.com)
+- [Airtable](https://airtable.com)
+- [SmartSheet](https://www.smartsheet.com)
+
+Here are some more resources:
+
+- [Why Scrum](https://www.scrumalliance.org/why-scrum) from The Scrum Alliance
+- [Scrum Guide](http://www.scrumguides.org/scrum-guide.html) from Scrum.org
+- [Doing vs Being Agile](http://agilitrix.com/2016/04/doing-agile-vs-being-agile/)

guide/english/agile/scrummasters/index.md

@@ -0,0 +1,32 @@
+---
+title: Scrummasters
+---
+## Scrum Master
+
+The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.
+
+The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
+
+### Scrum Master's Job
+
+- Facilitating (not participating in) the daily standup
+- Helping the team maintain their burndown chart
+- Setting up retrospectives, sprint reviews or sprint planning sessions
+- Shielding the team from interruptions during the sprint
+- Removing obstacles that affect the team
+- Walking the product owner through more technical user stories
+- Encouraging collaboration between the Scrum team and product owner . 
+
+Typically a Scrummaster will ask the following qustions: 
+1. What did you do yesterday?
+2. What are you going to do today?
+3. Is there anything stopping your progress?
+
+Scrum masters are part of an Agile team. They can be developers or other functional members (wearing multiple hats) or functioning individually as a sole role in a team. Their main objective is to enhance the development using the Scrum framework.
+
+Often their role is to: guide the sprint planning, monitor daily standup, conduct retrospectives, ensure velocity is present, help Scoping of Sprints.
+
+#### More Information:
+
+- <a href="https://www.scrum.org/resources/what-is-a-scrum-master" target="_blank" rel="nofollow">What is a Scrum Master</a>
+- <a href="https://www.scrum.org/resources/scrum-guide" rel="nofollow">Scrum Guide</a> 

guide/english/agile/self-organization/index.md

@@ -0,0 +1,29 @@
+---
+title: Self Organization
+---
+## Self Organization
+
+
+In order to maintain high dynamics and agility of developed projects, all team members should mindfully share responsibility for product that is being developed.
+
+Vertically oriented organisational structures proved themself to be slow and inflexible with many levels of decision making. If a team wants to act fast and react dynamically to constantly changing environment, the organisational structure needs to be flat with members feeling strongly responsible for their input into the project.
+
+It does not mean that management is obsolete process in an agile self-organised team. It just has a different characteristic than in traditional approach (especially in large organisations, but not only), proving to be more effective when more supportive and advisory than despotic and direct.
+
+Foundation of self-organisation is trust and commitment of team's members.
+
+Scrum teams are said to be self organising. This means that the work done and generally the way it is done is left up to the team to decide - they are
+empowered by their managers to guide themselves in the ways that makes them most effective. The members of the team (Delivery Team, Product Owner, and
+Scrum Master) regularly inspect their behaviors to continuously improve. 
+
+During Sprint Planning the team will look at the product backlog (which will have been prioritised by the product owner) and decide which stories they
+will work on in the upcoming sprint and the tasks which will need completing to mark the story as Done. The team will estimate a score or size for the
+story to denote effort. 
+
+During a sprint it is up to the members of the team to pick up sprint backlog stories to work on, generally they will pick ones they think they can
+achieve. Due to it being a self organising team, there should be no assigning a task to a team member by someone else.
+
+#### More Information:
+- Scrum.org on [Scrum Promoting Self Organization](https://www.scrum.org/resources/blog/how-does-scrum-promote-self-organization)
+- Scrum.org on [Scrum Roles Promoting Self Organization](https://www.scrum.org/resources/blog/how-do-3-scrum-roles-promote-self-organization)
+- Scrum Alliance on [What and How of Self Organization](https://scrumalliance.org/community/articles/2013/january/self-organizing-teams-what-and-how)

guide/english/agile/spikes/index.md

@@ -0,0 +1,23 @@
+---
+title: Spikes
+---
+## Spikes
+
+Not everything your team works on during the Sprint are User Stories. Sometimes, a user story cannot be effectively estimated or research is required. Maybe help is needed to decide between different architectures, to rule out some risks, or it may be a Proof of Concept (POC) to demonstrate a capability.
+
+In these cases, a Spike is added to the Sprint Backlog. The Acceptance Criteria for the Spike should be an answer to the question being posed. If the experiment is more difficult than anticipated, then maybe the answer is negative. (That's why the Spike should be limited in time.) 
+
+The time and energy invested in the Spike are intentionally limited so that the work can be completed within the Sprint while other User Stories are minimally impacted. The Spike does not usually receive a Story Point Estimate, but is given a fixed number of hours to be worked on.
+
+Demonstrate the results of the Spike in the Sprint Review. Based on the new information, the original question is reframed as a new User Story in a future Sprint.
+
+Your team gained the information necessary to make better decisions; to reduce uncertainty. With a small, measured amount of its resources to increase the quality and value of work in future Sprints, as opposed to making decisions based on guess-work.
+<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds  -->
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+- Mountain Goat Software [Spikes](https://www.mountaingoatsoftware.com/blog/spikes)
+- Scrum.org Forum [How to Integrate a Spike](https://www.scrum.org/forum/scrum-forum/5512/how-integrate-spike-scrum)
+- Scrum Alliance [Spikes and Effort-to-Grief Ratio](https://www.scrumalliance.org/community/articles/2013/march/spikes-and-the-effort-to-grief-ratio)
+- Wikipedia [Spike](https://en.wikipedia.org/wiki/Spike_(software_development))
+

guide/english/agile/sprint-backlog/index.md

@@ -0,0 +1,11 @@
+---
+title: Sprint Backlog
+---
+## Sprint Backlog
+
+The Sprint Backlog is a list of tasks identified by the Scrum Team to be completed during the Scrum Sprint. During the Sprint Planning meeting, the team selects a number of Product Backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each user story. 
+
+It is critical that the team itself selects the items and size of the Sprint Backlog. Because they are the people implementing / completing the tasks, they must be the people to choose what they are forecating to achive during the Sprint.
+
+#### More Information:
+[Scrum Guide: Sprint Backlog](http://www.scrumguides.org/scrum-guide.html#artifacts-sprintbacklog)

guide/english/agile/sprint-planning-meetings/index.md

@@ -0,0 +1,25 @@
+---
+title: Sprint Planning Meeting
+---
+## Sprint Planning Meeting
+
+The Sprint Planning is facilitated by the team's Scrum Master and consists of the Scrum Team: Development Team, Product Owner (PO) and Scrum Master (SM). It aims to plan a subset of Product Backlog items into a Sprint Backlog. The Scrum Sprint is normally started in after the Sprint Planning meeting. 
+
+### Main part
+It is of high value for the team to part the meeting in two parts by asking this two questions: 
+* **What** should the team plan for the upcoming Sprint? 
+* **How** should the team (roughly) takle the items planned?
+
+#### What
+In What phase the team starts with the top of the ordered Product Backlog. The team at least implicitly estimates the items by forecasting what they could take into Sprint Backlog. If needed they could ask / discuss items with the PO, who has to be in place for this meeting. 
+
+#### How
+In How phase the team shortly discusses every picked Sprint Backlog item with the focus on how they will takle it. SM helps the team not to deep dive into discussion and implementation details. It is very likely and good if more questions to the PO are asked or refinements to the items, or backlog is done by the team. 
+
+### Sprint Goal / Closing
+The team should come up with a shared Sprint Goal for the Sprint to keep the focus in the Sprint time box. At the end of the Sprint Planning the team forecasts that they can achieve the Sprint Goal and complete most likely all Sprint Backlog items. The SM should prevent the team to overestimate by providing useful insights or statistics. 
+
+#### More Information:
+[Scrum Guide: Sprint Planning](http://www.scrumguides.org/scrum-guide.html#events-planning)
+[Simple Cheat Sheet to Sprint Planning Meetings](https://www.leadingagile.com/2012/08/simple-cheat-sheet-to-sprint-planning-meeting/)
+[Four Steps for Better Sprint Planning](https://www.atlassian.com/blog/agile/sprint-planning-atlassian)

guide/english/agile/sprint-planning/index.md

@@ -0,0 +1,18 @@
+---
+title: Sprint Planning
+---
+
+## Sprint Planning
+
+In Scrum, the sprint planning meeting is attended by the product owner, ScrumMaster and the entire Scrum team. Outside stakeholders may attend by invitation of the team, although this is rare in most companies.
+During the sprint planning meeting, the product owner describes the highest priority features to the team. The team asks enough questions that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog.
+
+There are two defined artifacts that result from a sprint planning meeting:
+- A sprint goal
+- A sprint backlog
+
+Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box. 
+
+#### More Information:
+* https://www.mountaingoatsoftware.com/agile/scrum/meetings/sprint-planning-meeting
+* [Scrum Guide](http://www.scrumguides.org/scrum-guide.html)

guide/english/agile/sprint-review/index.md

@@ -0,0 +1,31 @@
+---
+title: Sprint Review
+---
+## Sprint Review
+
+The Sprint Review is one of the key Scrum ceremonies (along with Sprint Planning, the Daily Stand Up, the Retrospective, and Grooming).
+
+At the end of the Sprint, your Scrum team hosts an "Invite the World" session to showcase what has just been Completed and Accepted. Invited are the Scrum Team, Stakeholders, Managers, Users; anyone with an interest in the project.
+
+Holding these sessions every Sprint is important. It may be a mindset shift; showing unfinished work to your managers and stakeholders. But in the concept of "Fail Fast", there is incredible value in getting feedback on your incremental work. Your team can course-correct if necessary,  minimizing work lost. 
+
+Since the Product Owner (PO) is often presenting at the Sprint Review, the Scrum Master will usually capture the feedback, perhaps facilitate the discussions, and then work with the PO to get new User Stories added to the Backlog and prioritized.
+
+The agenda may also include a review of the Backlog (including value and priority), what is scheduled for the next Iteration or two, and what can be removed from the Backlog.
+
+**IMPORTANT** The Sprint Review is completely different than the Retrospective. The Retrospective is stricly for the Scrum team (Scrum Master, PO and Delivery Team). The other parties that are invited to the Review are excused from, and will likely interfere with, the Retrospective. (Yes, including Managers.)
+
+<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds  -->
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+Ken Rubin of Innolution <a href='https://www.scrumalliance.org/community/spotlight/ken-rubin/january-2015/stop-calling-your-sprint-review-a-demo%E2%80%94words-matte' target='_blank' rel='nofollow'>Stop Calling Your Sprint Review a Demo</a>
+
+Scrum.org <a href='https://www.scrum.org/resources/what-is-a-sprint-review' target='_blank' rel='nofollow'>What is a Sprint Review</a>
+
+Mountain Goat Software <a href='https://www.mountaingoatsoftware.com/agile/scrum/meetings/sprint-review-meeting' target='_blank' rel='nofollow'>Sprint Review Meeting</a>
+
+Atlassian <a href='https://www.atlassian.com/blog/agile/sprint-review-atlassian' target='_blank' rel='nofollow'>Three Steps for Better Sprint Reviews</a>
+
+Age of Product <a href='https://age-of-product.com/sprint-review-anti-patterns/' target='_blank' rel='nofollow'>Sprint Review Anti Patterns</a>
+

guide/english/agile/sprints/index.md

@@ -0,0 +1,21 @@
+---
+title: Sprints
+---
+## Sprints
+
+In Scrum, the **Sprint** is a period of working time usually between one and four weeks in which the delivery team works on your project. Sprints are iterative, and continue until the project is completed. Each sprint begins with a Sprint Planning session, and ends with Sprint Review and Retrospective meetings. Using sprints, as opposed to months-long waterfall or linear sequential development methodologies, allows regular feedback loops between project owners and stakeholders on the output from the delivery team.
+
+## Properties of a Sprint
+-Sprints should remain the same pretetermined length of time throughout the length of the project. 
+-The team works to break up the User Stories to a size that can be completed within the duration of the Sprint without carrying over to the next. 
+-"Sprint" and "Iteration" are often used interchangeably.
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+- Agile Alliance on <a href='https://www.agilealliance.org/glossary/iteration/' target='_blank' rel='nofollow'>Iterations</a>
+- Agile Alliance on <a href='https://www.agilealliance.org/glossary/timebox/' target='_blank' rel='nofollow'>Timeboxes</a>
+- Agile Coach on <a href='http://agilecoach.typepad.com/agile-coaching/2014/02/sprint-vs-iteration.html' target='_blank' rel='nofollow'>Sprint vs Iteration</a>
+- Scrum Alliance <a href='https://www.scrumalliance.org/community/articles/2014/february/timeboxing-a-motivational-factor-for-scrum-teams' target='_blank' rel='nofollow'>Timeboxing as a Motivational Factor</a>
+- Scrum Alliance <a href='https://www.scrumalliance.org/community/articles/2014/may/sprint-is-more-than-just-a-timebox' target='_blank' rel='nofollow'>Sprint is More Than Just a Timebox</a>
+- Scrum Inc <a href='https://www.scruminc.com/what-is-timeboxing/' target='_blank' rel='nofollow'>What is Timeboxing</a>
+- Scrum.org <a href='https://www.scrum.org/resources/what-is-a-sprint-in-scrum' target='_blank' rel='nofollow'>What is a Sprint in Scrum</a>

guide/english/agile/stakeholders/index.md

@@ -0,0 +1,23 @@
+---
+title: Stakeholders
+---
+## Stakeholders
+
+The Stakeholders are the people that will benefit from your project. It is up to the Product Owner to understand the outcome required by the Stakeholders, and to communicate that need to the Delivery Team.
+Stakeholders may be made up from any of the following
+- Users
+- Customers
+- Managers
+- Funders / investors
+
+Their participation in the project is essential for success.
+
+For example, when your team is performing the Sprint Review meetings, the demonstration of the project is for the stakeholders, and their feedback is captured and added to the backlog.
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+- Scrum Study <a href='https://www.scrumstudy.com/blog/stakeholders-in-scrum/' target='_blank' rel='nofollow'>Stakeholders in Scrum</a>
+- Scrum.org <a href='https://www.scrum.org/resources/blog/scrum-who-are-key-stakeholders-should-be-attending-every-sprint-review' target='_blank' rel='nofollow'>Key Stakeholders</a>
+- Agile Modelling <a href='http://agilemodeling.com/essays/activeStakeholderParticipation.htm' target='_blank' rel='nofollow'>Active Stakeholder Participation</a>
+
+

guide/english/agile/story-points-and-complexity-points/index.md

@@ -0,0 +1,23 @@
+---
+title: Story Points and Complexity Points
+---
+## Story Points and Complexity Points
+
+In Scrum/Agile, the functionality of a product in development is explored by way of **stories** a user might tell about what they want from a product. A team uses **Story Points** when they estimate the amount of effort required to deliver a user story.
+
+Notable features of story points are that they:
+
+* represent the contributions of the whole team
+* do not equate directly to time the task might take
+* are a rough measure for planning purposes - similar to orders of magnitude
+* are assigned in a Fibonacci-like sequence: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100
+* estimate the 'size' of stories *relative to each other*
+
+The concept of story points can be quite elusive if you are new to Agile ways of doing things. You will find many online sources discussing story points in different ways, and it can be hard to get a clear idea of what they are and how they are used.
+
+As you learn about the principles and terminology of practices like Scrum, the reasons for some of these properties will become apparent. The use of story points, especially in 'ceremonies' such as planning poker, is much easier to understand by observing or taking part than in a written explanation!
+
+### More Information:
+- User Stories: <a href='https://guide.freecodecamp.org/agile/user-stories' target='_blank' rel='nofollow'>freeCodeCamp</a>
+- Common mistakes when using story points: <a href='https://medium.com/bynder-tech/12-common-mistakes-made-when-using-story-points-f0bb9212d2f7' target='_blank' rel='nofollow'>Medium</a>
+- Planning Poker: <a href='https://www.mountaingoatsoftware.com/agile/planning-poker' target='_blank' rel='nofollow'>Mountain Goat Software</a>

guide/english/agile/sustainable-pace/index.md

@@ -0,0 +1,13 @@
+---
+title: Sustainable Pace
+---
+## Sustainable Pace
+
+A Sustainable Pace is the pace at which you and your team can work for extended periods, even forever.
+It respects your weekends, evenings, holidays, and vacations. It allows for necessary meetings and personal development time.
+
+
+
+#### More Information:
+[What is Sustainable Pace?](http://www.sustainablepace.net/what-is-sustainable-pace)
+

guide/english/agile/task-boards-and-kanban/index.md

@@ -0,0 +1,30 @@
+---
+title: Task Boards and Kanban
+---
+## Task Boards and Kanban
+Kanban is an excellent method both for teams doing software development and individuals tracking their personal tasks.
+
+Derived from the Japanese term for "signboard" or "billboard" to represent a signal, the key principal is to limit your work-in-progress (WIP) to a finite number of tasks at a given time. The amount that can be In Progress is determined by the team's (or individual's) constrained capacity. As one task is finished, that's the signal for you to move another task forward into its place.
+
+Your Kanban tasks are displayed on the Task Board in a series of columns that show the state of the tasks. In its simplest form, three columns are used
+- To Do
+- Doing 
+- Done
+
+![Kanban Board Example](https://upload.wikimedia.org/wikipedia/commons/thumb/d/d3/Simple-kanban-board-.jpg/600px-Simple-kanban-board-.jpg)
+
+*Image courtesy of <a href='https://en.wikipedia.org/wiki/Kanban_board' target='_blank' rel='nofollow'>Wikipedia</a>*
+
+But many other columns, or states, can be added. A software team may also include Waiting to Test, Complete, or Accepted, for example.
+
+![More Complicated Example](https://mktgcdn.leankit.com/uploads/images/general/_2048xAUTO_fit_center-center/1-SmalDevelopmentTeamKanbanBoard-eb79376d.png)
+
+*Image courtesy of <a href='https://leankit.com/learn/kanban/kanban-board-examples-for-development-and-operations/' target='_blank' rel='nofollow'>leankit</a>*
+
+### More Information:
+- What is Kanban: <a href='https://leankit.com/learn/kanban/what-is-kanban/' target='_blank' rel='nofollow'>Leankit</a>
+- What is Kanban: <a href='https://www.atlassian.com/agile/kanban' target='_blank' rel='nofollow'>Atlassian</a>
+
+Some online boards
+- <a href='https://trello.com/' target='_blank' rel='nofollow'>Trello</a>
+- <a href='https://kanbanflow.com' target='_blank' rel='nofollow'>KanbanFlow</a>

guide/english/agile/technical-debt/index.md

@@ -0,0 +1,16 @@
+---
+title: Technical Debt
+---
+## Technical Debt
+Often in agile development, if you are producing software in the "good enough" practice, you will also be adding to your technical debt. This is the accumulation of short cuts and work-arounds.
+
+Compare it to money. When you charge something on a credit card, you've made a commitment to pay it back later. When you create technical debt, your team *should* commit to addressing those issues on a schedule.
+
+One of the benefits of working iteratively is to frequently showcase your increments and gather feedback. If your first pass is "good enough", and changes are required as a result of that feedback, you may have avoided some unnecessary work. Capture this in your backlog, and include a portion in each sprint to be refactored or improved.
+<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds  -->
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+- The Agile Alliance on <a href='https://www.agilealliance.org/introduction-to-the-technical-debt-concept/' target='_blank' rel='nofollow'>Technical Debt</a>
+- Scrum Alliance on <a href='https://www.scrumalliance.org/community/articles/2013/july/managing-technical-debt' target='_blank' rel='nofollow'>Managing Technical Debt</a>
+

guide/english/agile/test-driven-development/index.md

@@ -0,0 +1,35 @@
+---
+title: Test Driven Development
+---
+## Test Driven Development
+
+Test Driven Development (TDD) is one of Agile Software Development approaches. It is based on the concept that
+> you must write a test case for your code even before you write the code
+
+Here, we write unit test first and then write the code to complete the test successfully. This saves time spend to perform unit test and other similar test, as we are going ahead with the successful iteration of the test as well leading to achieve modularity in the code. 
+It's basically composed of 4 steps
+
+ - Write a test case
+ - See the test fail (Red)
+ - Make the test pass, comitting whatever crimes in the process (Green)
+ - Refactor the code to be up to standards (Refactor)
+
+ These steps follow the principle of Red-Green-Refactor. Red-Green make sure that you write the simplest code possible to solve the problem while the last step makes sure that the code that you write is up to the standards.
+
+Each new feature of your system should follow the steps above.
+
+![tdd flow](http://www.agiledata.org/images/tddSteps.jpg)
+<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds  -->
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+Agile Data's <a href='http://agiledata.org/essays/tdd.html' target='_blank' rel='nofollow'>Introduction to TDD</a>
+
+Wiki on <a href='https://en.wikipedia.org/wiki/Test-driven_development' target='_blank' rel='nofollow'>TDD</a>
+
+Martin Fowler <a href='https://martinfowler.com/articles/is-tdd-dead/' target='_blank' rel='nofollow'>Is TDD Dead?</a>
+ (A series of recorded conversations on the subject)
+ 
+ Kent Beck's book <a href='https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530' target='_blank' rel='nofollow'>Test Driven Development by Example</a>
+
+Uncle Bob's <a href='http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html' target='_blank' rel='nofollow'>The Cycles of TDD</a>

guide/english/agile/the-agile-manifesto/index.md

@@ -0,0 +1,43 @@
+---
+title: The Manifesto
+---
+## The Manifesto
+
+
+### Origin
+
+> On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground—and of course, to eat. […] Now, a bigger gathering of organizational anarchists would be hard to find, so what emerged from this meeting was symbolic—a Manifesto for Agile Software Development—signed by all participants. (1)
+
+### Manifesto for agile software development
+
+We are uncovering better ways of developing software by doing it and helping others do it. 
+
+Through this work, we have come to value
+
+- **Individuals and interactions** over process and tools.
+- **Working software** over comprehensive documentation.
+- **Customer collaboration** over contract negotiation.
+- **Responding to change** over following a plan.
+
+That is, while there is value in the items on the right, we value the items on the left more.
+
+### Twelve Principles of Agile Software
+
+ 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
+ 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
+ 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
+ 4. Business people and developers must work together daily throughout the project.
+ 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
+ 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
+ 7. Working software is the primary measure of progress.
+ 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
+ 9. Continuous attention to technical excellence and good design enhances agility.
+ 10. Simplicity–the art of maximizing the amount of work not done–is essential.
+ 11. The best architectures, requirements, and designs emerge from self-organizing teams.
+ 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
+
+
+#### More Information:
+
+* [(1) History: The Agile Manifesto](http://agilemanifesto.org/history.html)
+* [Agile Manifesto](http://agilemanifesto.org/)

guide/english/agile/user-acceptance-tests/index.md

@@ -0,0 +1,56 @@
+---
+title: User Acceptance Tests
+---
+## User Acceptance Tests
+
+In engineering and its various subdisciplines, acceptance testing is a test conducted to determine if the requirements of a specification or contract are met. It may involve chemical tests, physical tests, or performance tests.
+
+In systems engineering it may involve black-box testing performed on a system (for example: a piece of software, lots of manufactured mechanical parts, or batches of chemical products) prior to its delivery.
+
+In software testing the ISTQB defines acceptance as: formal testing with respect to user needs, requirements, and business processes conducted to determine whether a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system. Acceptance testing is also known as user acceptance testing (UAT), end-user testing, operational acceptance testing (OAT) or field (acceptance) testing.
+
+A smoke test may be used as an acceptance test prior to introducing a build of software to the main testing process.
+
+One of the final steps in software testing is user acceptance testing (UAT). UAT makes sure actual users can use the software. Also referred to as beta, application, and end-user testing. 
+
+UAT checks that everything works properly and that there are no crashes. Those of the intended audience should complete the testing; this could be comprised of many people involved from the process and anyone who is able to test before going live.  The feedback from this testing is forwarded to the development team for any specific changes.
+  
+
+#### Why do we need UAT
+
+* Requirement changes might not have communicated to the developers
+
+* The software may not be delivering actually what it meant for
+
+* Some logic or business process may need user's attention
+
+
+#### What is required before we start UAT
+
+* Complete requriement is signed off and is available as documented
+
+* The code is in working or in demoable condition
+
+* UAT is environment is ready for access
+
+* There should not be any defect which will break the code
+
+* Test data prepared in accordance with the LIVE scneario
+  
+
+#### Framework & tools used
+
+* FitNesse
+
+
+#### Articles about UAT
+
+* [7 KEYS TO A SUCCESSFUL USER ACCEPTANCE TESTING](http://blog.debugme.eu/successful-user-acceptance-testing/)
+
+* [AgileUAT: A Framework for User Acceptance Testing
+based on User Stories and Acceptance Criteria](http://research.ijcaonline.org/volume120/number10/pxc3903533.pdf)
+
+
+#### More Information:
+https://en.wikipedia.org/wiki/Acceptance_testing
+

guide/english/agile/user-stories/index.md

@@ -0,0 +1,24 @@
+---
+title: User Stories
+---
+User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.
+
+User stories are typically written using the following pattern:
+#### As a [ type of user ], I want [ some goal ] so that [ some reason or need ]
+
+User stories should be written in non-technical terms from the perspective of the user. The story should emphasize the need of the user, and not the how. There should be no solution provided in the user story.
+
+One common mistake that is made when writing user stories is writing from the perspective of the developer or the solution. Be sure to state the goal and the need, and the functional requirements come later.
+
+#### Sizing a User Story: Epics and Smaller Stories
+An epic is a big, coarse-grained story. It is typically broken into several user stories over time—leveraging the user feedback on early prototypes and product increments. You can think of it as a headline and a placeholder for more detailed stories.
+
+Starting with epics allows you to sketch the product functionality without committing to the details. This is particularly helpful for describing new products and features: It allows you to capture the rough scope, and it buys you time to learn more about how to best address the needs of the users.
+
+It also reduces the time and effort required to integrate new insights. If you have many detailed stories in the product backlog, then it’s often tricky and time-consuming to relate feedback to the appropriate items and it carries the risk of introducing inconsistencies.
+
+When thinking about possible stories, it is also important to consider "mis-user cases" and "unhappy path" stories.  How will exceptions be handled by the system?  What kind of messaging will you provide back to user?  How would a malicious user abuse this application function?  These mal-stories can save rework and become usful test cases in QA.
+
+#### More Information:
+- <a href='https://www.mountaingoatsoftware.com/agile/user-stories' target='_blank' rel='nofollow'>Mountain Goat Software Guide to User Stories</a>
+- <a href='http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/' target='_blank' rel='nofollow'>Roman Pichler Guide to User Stories</a>

guide/english/agile/value-stream-mapping/index.md

@@ -0,0 +1,15 @@
+---
+title: Value Stream Mapping
+---
+## Value Stream Mapping
+
+**Value stream mapping** is a lean software development technique. It helps to identity the waste in resources in terms of material, effort, cost and time.  
+
+Calculating the process cycle efficiency is one of the ways to find out the efficiency of the AS-IS process.
+
+**Process cycle efficiency = Value-added time spent / total cycle time.**   
+
+The higher the value the better the efficiency.  
+
+#### More Information:
+* [Wikipedia](https://en.wikipedia.org/wiki/Value_stream_mapping)

guide/english/agile/vanity-metrics/index.md

@@ -0,0 +1,29 @@
+---
+title: Vanity Metrics
+---
+## Vanity Metrics
+
+Where Vanity is the value of appearance over quality, Vanity Metrics are measurements that, without context or explanation, are used to make someone or something look good. Eric Ries, posting at <a href='https://hbr.org/2010/02/entrepreneurs-beware-of-vanity-metrics' target='_blank' rel='nofollow'>Harvard Business Review</a>, suggests metrics should be **actionable**, **accessible**, and **auditable** to have meaning.
+
+![Vanity Metrics](https://i.pinimg.com/originals/d4/ea/9a/d4ea9ade0de05a5707e11b325a37d5fb.jpg)
+
+Examples:
+- Registered users vs Active users
+- User stories accepted vs Value delivered to the customer
+- Twitter followers vs Retweets
+
+![Value Matters](https://blog.kissmetrics.com/wp-content/uploads/2012/01/increasing-pageviews-flat-revenues.png)
+_image via kissmetrics_
+
+<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds  -->
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+
+Fizzle on <a href='https://fizzle.co/sparkline/vanity-vs-actionable-metrics' target='_blank' rel='nofollow'>Actionable vs Vanity Metrics</a>
+
+Harvard Business Review on <a href='https://hbr.org/2010/02/entrepreneurs-beware-of-vanity-metrics' target='_blank' rel='nofollow'>Vanity Metrics</a>
+
+Forbes <a href='https://www.forbes.com/sites/sujanpatel/2015/05/13/why-you-should-ignore-vanity-metrics-focus-on-engagement-metrics-instead/#1342fdeb12a9' target='_blank' rel='nofollow'>Ignore Vanity Metrics and Focus on Engagement</a>
+
+kissmetrics <a href='https://blog.kissmetrics.com/throw-away-vanity-metrics/' target='_blank' rel='nofollow'>Throw Away Vanity Metrics</a>

guide/english/agile/velocity/index.md

@@ -0,0 +1,11 @@
+---
+title: Velocity
+---
+## Velocity
+
+On a Scrum team, you determine the velocity at the end of each Iteration. It is simply the sum of Story Points completed within the timebox.
+
+Having a predictable, consistent velocity allows your team to plan your iterations with some confidence, to work sustainably, and to forecast,  with empirical data, the amount of scope to include in each release.
+
+#### More Information:
+The Scrum Alliance on <a href='https://www.scrumalliance.org/community/articles/2014/february/velocity' target='_blank' rel='nofollow'>Velocity</a>

guide/english/agile/voice-of-the-customer/index.md

@@ -0,0 +1,16 @@
+---
+title: Voice of the Customer
+---
+## Voice of the Customer
+
+You, as the Product Owner (PO), are the Voice of the Customer to the Delivery Team. When the team needs clarification on a story, to better understand the What and the Why, they will ask you.<BR>
+You understand the needs, motivations and  desired outcomes of the customer as they change over the length of the project.
+
+#### More Information:
+<!-- Please add any articles you think might be helpful to read before writing the article -->
+Scrum Alliance on the <a href='https://www.scrumalliance.org/community/articles/2014/july/who-is-your-product-owner' target='_blank' rel='nofollow'>Product Owner</a>
+
+Agile Alliance on the <a href='https://www.agilealliance.org/glossary/product-owner/' target='_blank' rel='nofollow'>Product Owner</a>
+
+
+