Having a product owner who is an expert on product requirements and customer needs.

Keeping the product backlog updated and prioritized in order to respond quickly to change.

Demonstrating working functionality to customers in every sprint review.

Delivering products to market quicker and more often with every release.

Possessing the potential for self-funding projects.

Higher team morale: Being part of a self-managing team allows people to be creative, innovative, and acknowledged for their expertise. Having a scrum master removes impediments and shields the development team from external interference. Working cross-functionally allows development team members to learn new skills and to grow by teaching others.

Increased collaboration and ownership: The development team, the product owner, and the scrum master work closely together on a daily basis. Daily scrum meetings let the development team organize around work completed, future work, and roadblocks. During sprint reviews the development team can demonstrate and discuss the product directly with stakeholders.

Customized team structures: Self-management puts decisions that would normally be made by a manager or the organization into scrum team members' hands. Because of the limited size of development teams — five to nine people — agile projects can have multiple scrum teams on one project. Self-management and size-limiting mean that agile projects can provide unique opportunities to customize team structures and work environments.

More relevant metrics: The metrics agile project teams use to estimate time and cost, measure project performance, and make project decisions are often more relevant and more accurate than metrics on traditional projects. On agile projects, you provide metrics by

Determining project timelines and budgets based on each development team's actual performance and capabilities

Having the development team that will be doing the workprovide effort estimates for project requirements

Using relative estimates, rather than hours or days, to tailor estimated effort to an individual development team's knowledge and capabilities

Refining estimated effort, time, and cost on a regular basis, as the development team learns more about the project

Updating the sprint burndown chart every day to provide accurate metrics about how the development team is performing within each sprint

Comparing the cost of future development with the value of that future development, which helps project teams determine when to end a project and redeploy capital to a new project

Improved performance visibility: On agile projects, every member of the project team has the opportunity to know how the project is going at any given time. Daily scrum meetings, daily sprint reviews, and visible progress charts offer concrete ways to see progress.

Increased project control: The many opportunities to inspect and adapt throughout agile projects allow all members of the project team — the development team, product owner, scrum master, and stakeholders — to exercise control and ultimately create better products.

Developing in sprints, ensuring a short time between initial project investment and either failing fast or knowing that a product or an approach will work

Always having a working product, starting with the very first sprint, so that no agile project fails completely

Developing requirements to the definition of done in each sprint so that project sponsors have completed, usable features, regardless of what may happen with the project in the future

Providing constant feedback on products and processes through daily scrum meetings and constant development team communication, sprint reviews and retrospectives, and releases in which the end user can see and react to new features on a regular basis

Generating revenue early with self-funding projects, allowing organizations to pay for a project with little up-front expense.