Have you ever heard something like: “Agile development expects that we can operate quickly, efficiently and effectively without necessarily having an overall strategic plan”? If so, forget it! Why? Try to build a house from the roof and see what happens!

Detailed planning is as essential to the effectiveness of Agile as it is to Waterfall. The difference between the two approaches lies in timing. Planning is ongoing in Agile, and its incremental approach allows projects to adapt rapidly to changes. Planning is predictive in Waterfall and the client knows exactly what to expect.

Predictive vs Adaptive Projects

Predictive projects are the ones in which the needs are not likely to change (at least we wish that they don’t change) and where the work being done can be “somewhat” identified and measured. Adaptive projects are those where requirements are likely to change – frequently in some cases – and the work is largely creative with high levels of uncertainty.

Categorize the Project

How can we correctly categorize our project? Here are some questions to guide us.

• Do we have requirements not well understood in advance and that are likely to change over the life of the project?
• Do we have a domain not well known in all its details?
• Are our teams trying to solve problems where the solution requires invention?

If we answered positively to the preceding questions, we’re probably facing with an adaptive environment; we should try to get an Agile approach to manage that kind of project, and the reason is that Agile provides the needed feedback mechanism to deliver adaptive projects.

How Much Will it Cost?

Okay, we decided to manage our project using an Agile approach. At the first progress review meeting, the management wants to know, “How much will it cost and how long will it take?” Organizational resources need to be allocated to the project. We need to provide feedback at a number of levels to answer the initial set of questions to ensure we are still delivering the best value for our organization’s investment. To effectively answer and satisfy our management, we need to provide them a plan.

Doing the Right Work and Doing the Work Right

In the initial phase of the project, when it’s not a real project but just an initiative to be funded, portfolio and program planning are needed to “do the right work”; in this phase planning is a high-level activity used to decide which initiative deserves to be funded.

When the initial filter has been passed and the initiative has been funded, the detailed activities provided by the analysis of the requirements has to be planned and this is about making sure that the team delivers against the product vision to provide business value on an iterative and incremental basis.

The Product Vision

The product vision is a really strategic means that clarify to the team why they are working, what they are working on and what key constraints they must work within. The vision is often detailed in a “Project Charter” document.

As an advice to get an “effective” charter, write it down with the whole team in a collaborative workshop with the project sponsor and product owner present. If the team members who will work on the product are not in the office, let’s get them together for the workshop in order to create a “one team” culture (it’ll be good also as a team building exercise).

If we get someone onboard after the vision has been created, let’s provide him/her a complete “training” using the project charter as a guide to help him/her understand the drivers behind the work being undertaken.

Typical contents of the project charter include:

• Problem/opportunity description
• Why should we deliver this project? What’s the value for our organization?
• How does the project align with the organization’s strategic goals?
• What are we trying to deliver? – let’s provide a high level solution description
• Key features of the product that we’re going to deliver
• Assumptions – where appropriate – and constraints
• Scope – what’s included and above all what’s excluded from our responsibility?
• Key timelines to deliver
• Budget and cost-benefit analysis
• Subordinated and/or related projects – let’s provide the key milestones of our project for alignment with those projects
• Risks with mitigation actions – where appropriate

There are some techniques that can be used to organize the “collaborative workshop” that will produce the product vision. A few are listed below:

The Elevator Statement

The “elevator statement”, also called the “elevator pitch”, is something that will enable any team member to explain the purpose of the project (a statement composed by a few sentences to explain the goals and objectives of the project) in the time it takes to ride between floors in an elevator (imagine you get into the elevator with the CEO of your company and you are asked to explain what the project is you are working on before the elevator gets to their floor).

Business Benefits Matrix

A simple matrix which articulates the strategic value that the product is intended to provide. The matrix looks like the following table:

There should only be one primary driver and there might be a number of secondary or tertiary goals. Where there is more than one goal in a column then they need to be ranked to avoid the “everything’s critical” conflict.

If we got this matrix filled up as a group activity, we’d help the team to understand the focus for the project.

Scope Matrix

We could use a simple “in/out list” to define what will be done, not be done and where there is uncertainty about deliverables. When we place an item in the “in” column, we state that the team is responsible for its delivery. When we place an item in the “out” column, we state that the team will not spend any time or effort on it.

When we are uncertain about an item being in scope or not, then we place it in the “undecided” column and the project manager needs to investigate further to identify if the team have to place it in the “in” or “out” column.

The Product Roadmap

At the beginning of our initiative we have to produce a product roadmap, a list of the most important features that the product will deliver to address the scope. Of course if we expect to deliver just one release of the product, the product roadmap will coincide with the release plan.

The product roadmap is a high-level plan maintained by the product owner and the project manager that is expected to change over time and is validated against the product vision (let’s remember to plan also the validation events).

The Release Plan

The release plan consists in the list of features that we’re going to deliver in the next release of the product. Of course the features included in the release plan are the ones that the product owner and the project manager agreed to release based on the prioritization made at the level of epics and stories.

A release consists of a number of iterations during which the team will deliver measurable value to the organization.

Stories and epics need to be sized (in story points or ideal days) and prioritized so that the work can be allocated to iterations.

Let’s see how this happens:

1. The product owner clarifies the goals for the next release.
2. The team discusses the needed features to address the goals.
3. The team discusses all factors that can influence the goals including risk and dependency between epics and stories. High risk-high value features should be taken home earlier than the others in order to easily adapt whether the risk evolves into a problem.
4. We plan the activities based on the team’s velocity. We could use an estimated initial team’s velocity as the starting point for planning the activities. For planning the activities for the next releases, of course, we should use the actual velocity and not the estimated initial one (unless the team changes significantly between releases). The simplest approach to guess the initial velocity is to ask our team members how many story points they think they can deliver during an iteration and plan based on that number. It will probably be wrong, but it could be a good enough starting point. 

Once we have the estimated velocity, it’s time to plan the iterations:

1. List the stories and epics for the release in priority order with their size.
2. Decide how many story points we can deliver in a single iteration – please consider the impact of idle time used for example to prepare the tools needed to work.
3. Add an iteration to the plan.
4. Add stories to the iteration till reaching the maximum capacity.
5. Share the plan and ask for feedback to get the highest commitment.

Let’s remember that the release plan is an adaptive plan and will change whenever we need.

The Iteration Plan

Every Agile team should be able to plan the activities included in an iteration based on the lessons from the work done in the previous iterations. They use the iteration planning to validate the release plan and produce the detailed iteration plan.

We should organize one or more sessions of iteration planning to analyze the release plan and update it based on any changes happened since the last update.

Changes could happen, for example, due to:

• velocity of the work delivered in previous iterations;
• priority changing in stories or epics; 
• introducing new stories and epics (e.g. as a result of a new risk identification); or
• recovering idle time that reduces the team’s ability to complete tasks.

During the first part of the meeting, the product owner explains the actual priorities and the team revises the iteration plan for identifying the stories to be done in the actual iteration.

The amount of stories included in the actual iteration will be based on “yesterday’s weather”, that is the team’s velocity based on the amount of work done in the previous iteration.

The reason behind the choice of establishing the velocity based on the amount of time needed to complete the previous iteration is that it’s very likely that the team will complete the same amount of work as they did before, unless they have been changed a lot or the working environment has been changed significantly.

The second phase of this meeting will consist in breaking the work down into specific tasks to be “pulled” by every team member during the next iteration, based on his/her ability to do the task in the amount of time initially estimated to complete it. Let’s keep the tasks’ size very small – from a few hours to a day or so.

Now it’s time to allocate the tasks and confirm the commitment of all team members and this is the due of the “iteration manager” (in Scrum he/she is the Scrum Master).

Let’s write the tasks down onto cards (e.g., colored post-it) and hang them up on a large and visible surface (e.g., the wall in the open space where the whole team can see it).

Let’s provide the team with an Iteration Backlog on which all members can find the stories and epics included in the actual iteration.

We could track the progress of all the tasks on a grid placed on the same wall where we placed the task cards. On the grid we could write down the task, who is responsible for completing it, the estimated time to complete it, the remaining hours to complete it and the actual hours used to complete it (so we could measure if we are late or not on our schedule).

The last grid should be completed by every team member to track his/her work against the tasks and represents their daily commitment.

To check our progress, we should use the so-called burndown chart that is a graph showing the initial estimate and the remaining effort for the iteration.

The burndown chart can be used by the team to try to improve their estimation skills in the next iteration planning meeting.

The “Daily Standup” Meeting

Daily meetings are the most important and effective tool used for communicating the progress within the iteration. Every day the whole team gets this meeting and the iteration manager asks the status of all tasks assigned to every team member.

There are a few simple rules to be taken into account and strictly followed by each member.

• It is held standing up and the maximum duration is 15 minutes (can you afford a standup meeting held for more than 15 minutes? Let me know if you can afford it every day…)
• No more than one minute for each member to expose the status of the task assigned to him/her.
• No deviation from the actual story / task and the status can be “Done” or “Not Done” – it’s not valid to say “I’m at 75%”; in that case, it’s “Not Done” and the member has to declare how many hours he/she needs to complete it.
• If a member has any obstacle to pass, he/she will declare it on a separate basis after the meeting.
• Each team member answers just to the following questions:
  • What have you done yesterday?
  • What will you do today?
  • What’s in your way? (“Nothing” means you’re going to complete the tasks respecting the estimated time without any expected obstacle.)

The iteration manager is responsible for removing all the obstacles declared by the team members (after the standup meeting) so the team can be fully productive.

Just one last rule: we have to keep in mind that we shouldn’t punish our team members for not meeting task commitments because otherwise our task force will adapt to the behavior and won’t tell the truth about the status of the tasks during the standup meeting.

We have to consider that sometimes we will estimate badly or something will happen that prevents someone from working on their task but that isn’t a bad thing, it should be a motivation to improve our skills.

When planning in any methodology you’ll want a tool robust enough to cover all the bases, including monitor that plan and then reporting on it. That’s where ProjectManager.com comes in. Its online and collaborative suite of software provides a project leader with the tools to do the job. Try it yourself with this free 30-day trial.