Agile, Agile Estimating, People, Project Management, Requirements

Agile Project Planning – 4 lightweight practices

How the heck Do you plan an Agile project?

If you listen to some Agile proponents out there you might think that Agile projects do not have a planning phase. You may have heard the following:

  • You shouldn’t create a plan as things will change and it will be wasted effort.
  • You shouldn’t create estimates as they will just be wrong and it will be wasted effort.
  • You should just start executing iterations and you will then determine your team’s velocity and what you can achieve.
  • You just keep on working on prioritized stories until the client tells you to stop or runs out of money.

As long as we are doing Agile projects we must first remember what a project is. A common definition is:

“a task or planned program of work that requires a large amount of time, effort, and planning to complete”

So really, any work cannot be termed a project without a plan. I would also add one additional criteria to what comprises a project. I believe a project requires two key criteria:

  • A plan that defines scope, cost, and schedule. (At whatever level deemed appropriate)
  • A vision of the solution that defines success for the project sponsor and the project team.

Too often I feel that projects are started without the vision fully crystalized. If there is not a vision of the solution, how can the following be determined?

  • How can the project team be sure the solution truly solves the business problem
  • How can the project team be sure that the solution is functionally and technically cohesive, consistent, and correct
  • How can the project team be sure that the project budget and schedule can deliver a solution that satisfies the minimum client success criteria?

Without taking the time to confirm the vision of the project we are risking the success of the project.

Kan Ban boards are not the Plan

What made me think about this? I have seen more and more Kan Ban boards which people use as the project plan. Kan Ban boards are intended to be visibility into the project plan and status, but should not be the project plan itself. There needs to be a plan outside of the Kan Ban board that defines the project plan with some amount of dependency management. In addition, a separate vision of the solution should also exist. (Both functionally and architecturally)

Without these two artifacts I would suggest that you may not have an actual project and your Kan Ban board may simply be stickies on a wall. 🙂

So how do you plan an Agile project?

Now I am not proposing a detailed work breakdown structure for an Agile project. I believe there are lightweight methods that can provide the value for minimal cost. I typically plan an Agile project in the following 4 ways.

  1. Ensure that Project kick off, Charter, and risk sessions are held. These are very short meetings but start to ensure that all team members share a common understanding of what the project is expected to achieve.
  2. Hold a Rapid Discovery Event to confirm the scope, objectives, and high-level plan of the project. This session should  take only 1-2 weeks for a 3-6 month project. This event is critical to build a common understanding of the vision and solution.
  3. Create and estimate the project schedule at a deliverable-level with dependency management to ensure that the project can deliver the minimum client scope, budget, and schedule requirements
  4. Gain agreement from the client as to how the Agile project will be run and the ‘rules of engagement’. We have already confirmed we think we can deliver the minimum functionality, so this meeting is focused on gaining agreement on the process of how we will work together to deal with change.

I’m not proposing a detailed project plan, requirement document, or architecture document, but a little work on all three can go a long way to ensure success.

Re-posted from

About Terry Bunio

Terry Bunio has worked for Protegra for 14+ years because of the professionalism, people, and culture. Terry started as a software developer and found his technical calling in Data Architecture. Terry has helped to create Enterprise Operational Data Stores and Data Warehouses for the Financial and Insurance industries. Along the way Terry discovered that he enjoys helping to build teams, grow client trust and encourage individual career growth, completing project deliverables, and helping to guide solutions. It seems that some people like to call that Project Management. As a practical Data Modeller and Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Data Modelling and Agile. Terry considers himself a born again agilist as Agile implemented according to the Lean Principles has made him once again enjoy Software Development and believe in what can be accomplished. Terry is a fan of Agile implemented according to the Lean Principles, the Green Bay Packers, Winnipeg Jets, Operational Data Stores, 4th Normal Form, and asking why


No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: