agile you meant Scrum, this would not be the exact way to go.
Scrum perspective, if you got a one year plan, you should at least have as many Sprints as there are months in a year. Hence, your one year plan is getting more agile since it is changeable between two Sprints.
Sprint can be no longer than a month, where the
Team commits to bring the
Sprint Backlog Items to the status of
Done is an important word here, and each of the
Scrum Team must have one definition of done, that is, where there is no work remaining to be done. When a
Sprint Backlog Item is Done, this means that the analysis, architecture and technical documentation is written, and that the feature has been thoroughly tested (unit tests, integration tests, functional tests...).
Product Backlog is in place, and the Items prioritized with less important features to the bottom, and the most important ones on top, the Team (of developers) determines how long should the development of each
Product Backlog Item shall take based on their own experience. That is where you may determine that the project will require a full year of work. Consider that only the
Product Owner shall prioritize the Items as it is he who is responsible for the return on investment, or else, knows what is the most important to the end-user. Plus, the Team shall evaluate the time required to fully develop a feature although there could be reusable pieces of code here and there that could suit the needs of this feature, that is, to avoid further complexity and be certain that an Item should take no longer than what the Team said it would require. The Product Backlog does not need to be perfect! The simple enumeration of user stories we can think of the system to develop is enough at that step of the process.
It is during the
Sprint Planning Meeting that the Team shall commit on what will be develop for the next
Sprint, hence creating the
Sprint Backlog. The
Sprint Backlog consists of a subset based on the
Product Backlog Items that the
Team commits to be done at the end of the Sprint. Considering for example a Product Backlog of 50 Items, and all the 50 Items shall require a year to be done, then the Team might want to select let's say 5 Items from the Product Backlog, and create the Sprint Backlog with these 5 Items. These same 5 Items may be expanded/exploded into multiple other Items when required, thus making the Team perhaps change their mind after revision and commit to do only 4 Items out of 5 previously selected Items from the Product Backlog.
Once the Sprint Planning Meeting is over, which can last no longer than 8 hours for a full month Sprint, within which the Team doesn't only commit to do the work for the selected Items, but plans on how it will get the job done so that everyone in the Team knows exactly what she/he has to do, the
Sprint shall begin. It is important for the Team to be cross-functional for the project's sake.
That said, at the end of each Sprint, which lasts a month in the current situation, all of the Items that the
Team committed to do shall be a deliverable piece of fully functional feature(s) targeting the Items selected from the Product Backlog. It has to be deliverable, but it is not obligatory that it is delivered if it does not make sense to do so according to the
It is during the
Sprint Review Meeting where the
Product Owner is required to be summoned that the
Team demonstrates what was done during the Sprint, and where it needs to tell why it has not done, if applicable, all the work it committed to. The undone work is then put back in the
Product Backlog and available for the next
Sprint. Sure these undone Items shall be included in the next Sprint unless otherwise told by the Product Owner, in case that the objective had changed. But most importantly, though the objective of a system changed during a Sprint, don't interrupt it unless absolutely necessary. Only the Product Owner has the authority to interrupt the Sprint.
Sprint Review Meeting is over, which should last no more than 4 hours for a monthly Sprint (if I remember correctly), it is time to get to the
Sprint Retrospective Meeting. The
Sprint Retrospective is required for the
Team to occur so that it may discuss, in the presence of the Scrum Master and the Product Owner (optional) what went wrong, how the Scrum Team may improve its performance, etc. and bring adjustments accordingly.
When the time-box for the
Sprint Retrospective is over, then the new
Sprint Planning Meeting shall occur to plan the next
Sprint and create the new
Team is responsible to maintain the
Daily Scrum which is a 15 minutes stand-up meeting where every Team Member answers the three questions (not in that particular order):
- What have you done since the last Daily Scrum?
- What do you plan to do until the next Daily Scrum?
- What are the problems or impediments that you encountered since the last Daily Scrum?
Scrum Master is not obliged to be there but is required to assure that the Team meets at the Daily Scrum and that the Members answer the three questions properly.
The Scrum Master is responsible for the respect of the Scrum Rules by the other Scrum Team Members (Scrum Master, Product Owner and Team).
In the end, following these simple rules, your development team will become agile. Agility is the capability to catch up on any change as fast as the Team can, that is, at the end of each Sprint, where it can get aware of the changes brought by the Product Owner to the Product Backlog. In case of total disaster and complete change of orientation, the maximum lost that the company has to absorb is a month of development, which is quite neglectable, considering that there are approximately only 20 working days in a month.
Should you require further detailed information about Scrum and Agile Software Development, please refer to Scrum.org and their Scrum Guide.
Well, that is quite an answer! I do hope this will at least help you through your project management.
While you're planning to do three or four phases, as you call it, it is more likely that your Team will lose focus from the primary objective point of view. If you demonstrate after only the first quarter what you Team has done, there might be some important changes to bring that will require important redesign and rethinking on the architecture of your software, resuming it of perhaps more than 20 days of work lost. The principle of agility is to be able to catch up with the changes as soon as they occur, or as soon as it is possible within a reasonable amount of time, that is, for Scrum, the time-box of a Sprint.