Agile is all about simplicity. Those who practice Agile methods long enough are guided by one of the twelve principles of Agile: "Simplicity - the art of maximizing the amount of work not done - is essential." The logic behind this statement is based on minimizing waste created by investing a lot of efforts into comprehensive project plans, which wouldn't survive first sprint review. However, the value of the planning process was once described by Dwight D. Eisenhower as:

In preparing for battle, I have always found that plans are useless but planning is indispensable.

Project planning uncovers a lot of hidden assumptions, risks and inconsistencies in understanding by team members. It is a great tool to help add important items to product backlogs, synchronize meaning of "done" work and prioritize backlog based not only by business value, but also by risks. On the other hand, spending a week or so for Sprint Zero Workshop is sometimes overkill for small projects.

Alistair Cockburn adopted Blitz Planning technique from Jens Coldewey for his Crystal Clear methodology. It is well described in his book so I would skip the theory and describe the experience of applying this technique in practice – which worked surprisingly well for a non-development team! Agile Practice now works on process optimization for IT Support department in Kyiv and this technique was chosen to do quick decomposition, prioritization and risks identification for one of the IT projects (moving infrastructure and working places into new office center):

Gather the Attendees (preparation phase)

Every key person (at least every role) involved in the project should be present and be ready to invest 90 minutes of their time into the creation of a meaningful project plan. Persons involved should have at least general knowledge of subject domain and/or architecture to be able to lay out tasks and identify dependencies.

In our example I gathered 5 persons: IT support head and lead experts fr om all IT support groups.

Define Project Goals (10 min)

Set project goals in S.M.A.R.T. format, in our example: "by all employees of projects , and are able to login into corporate domain, use network infrastructure and IP phones with access to all assigned project resources in new office

Brainstorm the Tasks (15 min)

All meeting members take stickers and markers and write whatever tasks come to their mind, needed to get project goals accomplished. No discussions happen at this moment.

Layout, Merge and Sort the Tasks (15 min)


Tasks are being laid out at the table in order of priority (given latter tasks depend on implementation of the first ones). Tasks running in parallel are aligned vertically.

Identify External Dependencies (20 min)

If there are dependencies on any external teams, vendors, and client employees which should provide information or resources - such tasks are marked somehow (for example, with a red asterisk). There could be different dependencies - from "Vendor supplies requested equipment" to "Client does acceptance testing of new feature/solution."

Add Tasks for Risk Mitigation (20 min)

This is an important part: every sticker marked on a previous step should be redesigned into an action item for the team. For example, helpless waiting for "Client does acceptance testing of new feature/solution" could be split into a series of action items:

  • Inform client on availability of solution for testing
  • Ask client about testing progress
  • Get feedback from client
  • Sign acceptance evidence with the client
All of such tasks have something in common - they don't imply someone would do their job for the team, but imply team responsibility for collaboration with 3rd parties to get the job done.

Identify "Walking Skeleton" and "Minimum Viable Product" (5 min)


Outline first stage of the project wh ere some meaningful output could be deployed to client to get feedback from a real environment. Think about reshuffling project tasks to get such result as quickly as possible.

Capture the Output (5 min)

Created backlog could be considered an important thing per se, but it is also important to identify tasks for the first iteration. An important note to add here is that we first envisioned the Kanban process for an IT support team but this Blitz Planning session has shown that for projects we need the process to be different from the regular Help Desk issues workflow (note merged columns in the middle of board - that's where we put tasks for long-term projects):


Total time spent: 90 minutes

Value from the Workshop: Clear Understanding of Project Goals, Tasks Backlog, Risks and Dependencies for Project Team

I didn't describe an estimation of the size and duration of tasks and overall project length - this is done intentionally as this could be done separately using, for example, Affinity Estimation technique.
If you're interested in running a workshop for Blitz Planning or would like to discuss your experience – please let us know at
Sergey Prokhorenko
Sergey has a computer science background and 18 years of experience in IT, including over 9 years in Agile scaling. Currently he combines several roles: Director of a company-wide Agile practice center of expertise with focus on growing a solid consulting offering and meeting challenging financial goals; Principal Agile consultant running presales, kick-starting new Agile engagements, driving organizational changes, coaching client executives and being a leader of a team of consultants; Agile promoter of modern management principles and practices through public speaking, supporting analyst firms and investor relations, running internal community Agile-related topics, and developing partnerships with 3rd parties. Sergey’s goal is to help organizations build sustainable and effective product development frameworks with a close focus on timely delivery of business value.