Some of the benefits of Agile Planning

Traditional	Agile	Comments
The plan is drawn up at the start of the project. Any deviations and changes are discouraged	A rough plan is put together at the start of the project. It is constantly reviewed and revised during the project, even on a daily basis	The plan is a living thing in agile
The Project Manager owns and shapes the plan	Everyone owns and shapes the plan	Everyone in an agile team understands project planning
Planning reporting and review is periodic (e.g. weekly)	Planning is reviewed constantly	The daily standup meeting ensures that the agile plan is updated every 24 hours.
Delivery only happens at the end	Delivery happens during the project	The product starts forming early on in the project, creating stakeholder confidence
The project is opaque	The project is visible via burndown charts and early releases	Stakeholders are constantly informed
The project delivers what was specified	The project delivers the most critical features	Agile is constrained by timeboxing and by a fixed small team
The project can run past the original timeline	The project is timeboxed. It completes on a specified date	The focus is on what can be delivered in the time allowed.
More resources can be added if necessary	The team size is fixed and stable	Agile teams mature and coalesce during the project.

Planning for Success with the Product Owner

It may come as a surprise to discover that the choice of the right Product Owner for a project and ensuring that he can work according to the dictates of Agile and Scrum is the biggest contributor to a successful project. Projects where the Product Owner is not immersed in the project, and is subject to outside interference could fail, no matter how experienced the development team that was chosen. The fundamental reason for this is that the Product Owner has the best understanding of the company environment and the clearest vision of how the new product will fit into that environment.

The Product Owner has the ultimate responsibility for a successful product, and achieves this by scrupulous attention to the product description, which is housed in an artefact called the Product Backlog. The product description differs from the traditional business requirements document in that all aspects of the product have been documented as “user stories”. These are atomic descriptions of an aspect of the product that are expressed from the standpoint of the product user. A typical story would be “I want to access the system…” describing how the user logs on to the application. User stories are preceded by “epics” which are broader descriptions of what the product should do. “Features” are descriptions of specific attributes of the product. Additional items that expand on the user stories and product features are also stored in the Backlog, and will be prioritised based on their relevance to any particular epic, feature or user story.

Recommended Further Reading

The following materials may assist you in order to get the most out of this course: