Assuming by project-management
and agile
you meant Scrum, this would not be the exact way to go.
In the 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.
A Sprint
can be no longer than a month, where the Team
commits to bring the Sprint Backlog Items
to the status of Done
.
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...).
Once the 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 Product Owner
.
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.
Once the 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 Sprint Backlog
.
Remember, the 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?
The 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.
EDIT #1
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.