In changing project environments, utilising the Agile methods is increasingly becoming a framework for mitigating risk, optimising for business value, scope, quality and schedule.  Agile methods are based on the incremental development process illustrated by Deming’s PDCA (plan-do-check-adjust) iteration cycle. Artefacts like User Stories and Velocity are used to define the product or service and progress against expected delivery dates by the project.  

User Story
Mike Cohn describes a user story as a “short, simple description of a feature told from the perspective of the person who desires the new capability”. The User story also contains acceptance criteria which are the conditions under which the feature would be accepted as completed work. A prioritised list of Stories by business value makes up the Product Backlog of which the Minimum Viable Product (MVP) is determined given the scope, cost, expected delivery dates amongst other factors for consideration. Thus in practice, the User Story which is commonly sized using a points system, loosely combines the concepts of scope, risk, complexity, quality and duration for a feature development.
Progress is determined only by the completion of User Stories that have been tested and met their acceptance criteria. The feature can then be reviewed by stakeholders to determine if the product or service is progressing towards expected results. Another advantage of accepting only completed stories is that it removes uncertainty and reliance on the intermediate states of partially completed work which can be misleading. The Velocity which is used to estimate schedule is determined by the number of completed User Stories or points in an iteration cycle.
In a quite transient environment, it is possible that environmental, technical or market changes could elicit the necessity for modification of the product or service. In more traditional settings this would ordinarily necessitate raising change requests and a sometimes lengthy approval process. In the Agile methods, change is a welcomed event because in principle, what is involved is a review of the User Stories that make up the backlog and re-prioritising the Stories to arrive to a new MVP and thus an updated schedule and cost given all the considerations.
One of the great advantages of a User Stories is that it encourages discussions between the implementation teams and the business or stakeholder which in many cases surfaces risks, unknowns and dependencies at an early stage.
Using the software paradigm as an example, if a product consists of a client, middleware and server side functionality, traditionally the different functions would work in separate teams. And at some point in the project a linear integration exercise would take place, which more often than not, unearths significant risks to the project. This is because discussions within each implementation team would have been limited to their functional areas without in depth discussion of the impact of the decisions to the other integrating parts.

Alternatively, an Agile development team would consist of personnel from the different functional teams and a representative from the stakeholder.  This encourages cross-functional discussions of the product or service as an end-to-end entity with a business focus. In this way of working, the implementation team takes a vertical slice, as much as reasonably possible, across the integrating parts towards a working potentially shippable product, as opposed to a big bang approach. Integration issues, dependencies and impacts across different business areas are surfaced early, discussed, assessed and addressed.
The finished slice is reviewed by stakeholders in a Showcase at the end of the iteration where any modification, suggestions, risks and questions are fielded. This forum also give the stakeholders confidence that the product or service is progressing in the expected direction towards meeting its business goals.

What is your advice about the best way to implement Agile methods?
Author: Etiene Isemin (All Rights Reserved by the author).
Source: Original Text (based upon first hand knowledge).
Help us to improve it: how-todiscussion.