There are a set of principles that if followed closely, help to ensure that a project plan is Agile. Please find below these principles.
- Plan at different levels
Agile utilizes Progressive Elaboration in its planning. Progressive Elaboration is the process of adding more details to a plan as new information emerges. At the onset of an Agile project, the scope is planned and a high-level definition of done is established for the project. Releases are planned in more detail creating a map of the features we would like delivered at different points in time. Iterations are then planned in even more detail, deciding what stories will be built in each iteration and then planning the tasks required to complete them. In summary, the further along an Agile project is, the more detailed the plans.
- Modify processes to fit the project’s characteristics
The larger the project, the more there is at stake and the more detailed the plan should be. In a situation whereby the project requirements and technologies are familiar and well understood, it is smarter, and safer to do more detailed or up-front planning than when there is a lack of clarity on the project scope. If on the other hand, the project is mostly exploratory and consequently there are a lot of uncertainties, it is recommended that the team plans in spikes (a short, timeboxed effort set aside for a Proof of Concept) to test and confirm that the chosen technological approach will be appropriate.
- Update the plan according to the project’s priorities
Agile project plans are continually reviewed and updated based on the customer’s business value and a focus on continuous improvement. The project priorities are reflected in the backlog list created by the Product Owner, working with the development team. Once the need for a change arises, which is frequent in an Agile environment, there will be a need to re-examine the backlog and release plans to determine if there is a need for other corresponding changes to be made. Sometimes a change in the requirements for a certain feature changes the priority of other features and this must be captured to ensure a smooth flow. For example, deciding that a particular story must be completed in the first iteration might mean moving other stories or tasks to future iterations as the iteration is time bound so opportunity cost must come into play by way of prioritization.
- Involve the team and the customer in planning
It is recommended that the customer is closely involved in the planning of an Agile project. The nature of knowledge work projects is such that often, the project leader will not have all the information necessary to satisfy the customer’s needs. Very frequently, the customers themselves are exploring a concept they are not entirely sure of as yet and so both the project team and customer need to collaborate on a close and on-going basis as this would help to ensure the customer’s buy-in at the end of the project. This can be achieved by engaging the customer early, building their confidence in the captured requirements/User Stories by getting it reviewed especially by the influential stakeholders. The Product Owner or Project Leader should also make sure to document the customer’s issues and requirements, follow up and resolve these issues early while still building draft. Get this backlog reviewed internally as well with the project team to ensure that at the very least, the minimum quality standard will be met. Finally, the Product Owner should ensure there is a structured walkthrough with the customer to gain consensus, approval and sign off and thus achieve a common understanding, this can be accomplished during a Sprint Review. Using this approach will take advantage of the team’s knowledge and technical insights and also generate the customer buy-in and commitment for the plan that is developed.
- Manage expectations through demonstrations of project progress and estimating velocity
Using different information radiators (large representations of project information kept plainly in sight within an agile development team’s shared workspace) along with the Sprint Review, Agile teams show what has been built as the process goes along. This helps to ensure that the stakeholders are carried along on what is being developed and helps to manage their expectations about what is being built and what they can expect at the end of the project. During the Sprint Review meeting, a working increment of the product will be demonstrated to stakeholders. This allows the team to get feedback and is an opportunity for the customer to discuss with the Product Owner and the team any changes to the Product Backlog which would help to maximise business value. The team should be mindful to use current or actual rate of progress, rather than assumptions or estimates to predict completion dates and costs.
- Ensure that estimates are comprehensive and include risks, interuptions and team availability
To effectively manage customer’s expectations, Agile projects need to use realistic estimates. Naturally, the project sponsors would want to know when things will be completed. This makes it expedient that estimates take into account known variables. To produce good estimates, the team needs to determine its estimates by using existing or past averages (such as velocity trends). Also required to produce a realistic estimate is capturing the availability of the team in the future, the occasional but inevitable distractions and diversions, and other calls on the team’s time that will most likely occur.
- Apply appropriate estimate ranges to represent its level of uncertainty
If we are working on a short-term goal that we are very familiar with and have repeatedly accomplished in the past, we can safely give a narrow estimate. An example might be the time required to complete a particular task that we have completed on several projects in the past. However, if there is a lot of uncertainty and a long timeline, many unforeseen issues might arise. To avoid complications that may arise because of time commitments we have made without considering the possibility of unforeseen circumstances, we should manage expectations by using a broader estimate range. To be on the safe side, our estimates should always say “depending on stakeholder’s availability and our schedule”.
- Ensure projections are based on past completion rates
In line with the previous point, as much as possible, the team’s plans and projections should be rooted on actual/confirmed completion data for the project. This is because these figures present the real, rather than ideal rate of progress on the project. These timelines already have the inevitable diversions and dead time captured, this means they are more likely to be repeated in the future than merely theoretical timelines. If given the option of using a theoretical timeline and a tried and tested timeline, use the latter.
- Make allowance for distractions and external work
On a final note, we all know that life happens; sometimes members of the team get pulled off to provide support on other, probably more critical projects. People take sick days off, family emergencies arise, vacations are required etc. Bearing this in mind then, we should be careful not to assume continuous availability of the project team members or stakeholders. These facts need to be borne in mind as we develop our project timeline to avert the risk of unrealistic expectations being presented to customers.