Agile, planning and fixed dates in no time

There are many commonly held myths about agile. Two of these myths are that agile projects don’t do any planning and that you can’t do agile on a fixed date project. On the other hand, organizations have customers they want to satisfy and operations to run. And sometimes they feel a need for planning, and sometimes they face a fixed date. Can we simple neglect these feelings or must we exclude such projects from our Agile world?

Valid requests for fixed date or mid-term planning
In my daily practice I meet questions like:

How much can be done by a given date? So that we can prepare our Sales people training in time.

When can this set of features for our product be shipped? So that our clients can prepare their systems for it in time.

How many teams do we need working on this project? So that we are in time for the due date set by the Regulations Authority. If we set off too slow, we know that catching up often is very hard and requests measures like doubling the capacity before you know.

When can I plan the project resources for another/next project? So that I know whether I need to hire extra resources or not.

Valid questions in my humble opinion. So, requests for mid-term planning statements can come with these questions in mind, and are not always meant to control and micromanage progress. How does Agile deal with this issue? Planning? Fixed date project? Agile? Yes, we can.
Before we start: Scope is variable
So, let us assume we are not in a perfect world yet. We don’t have a continuous flow of changes, which are realized in order of priority. Finished work items are not directly released at the end of each iteration. We are talking about a project like environment, in which the project is expected to deliver a certain set of requirements in, let’s say, 8 month’s time. And the organization is learning Agile.
Before diving into Agile planning and estimation I would like to stress the Agile approach: delivery date is fixed, scope is variable, and thus scope is your primary steer. This sounds easy, but turns out hard to bring into practice. Most managers feel their projects only start with just a set of must-have requirements left in scope. They are not spending money on fun features! I always point out that when the s**t hits the fan in former projects they always found functionality and features to be left out in the first release. Let us identify these now, upfront, and move those requirements to the end of our planning. Let us first build a working, minimal version, and then start adding functionality to make it acceptable for production. So, not 100 functions 80% finished, but 80 functions 100% done done. This way we have a choice when to release into production, or to wait a bit longer.
Details do not mean quality
Coming back on planning and estimation. To create the magic planning one needs to know:
• What needs to be done? (Product Backlog)
• How much work will it cost to complete this work? (estimations)
• How much work can we do in week? (velocity)
We used to make a projection of the result in as much detail as possible. This is commonly called an impact analysis, which includes both business requirements and a technical analysis. But precision is expensive, and more likely to be wrong. We are doing detailed impact analysis for decades now, and it turns out they are no guarantee for success, nor predictability. Be honest, what is your organizations track record regarding estimation and planning?
Experience learns that the quality of a light weight ‘Agile’ estimation and planning is at least as good as the details-based ones.
A widely complete backlog using story maps
Thus instead of investing weeks and months in a preparation phase that results in a detailed planning, try to think in hours or days. Set up the Product Backlog in a one day workshop. Take another day to answer emerging questions. All you need is a facilitator and the right people in the room. All of them. Story mapping is an excellent method for effective backlog creation. It is easy to learn and apply and it has a built-in end-to-end process approach. From an initial estimation point of view, the identification of the width of the requirements is far more important for accuracy, than the depth of the features.
Accurate estimations without details
Once you have created your initial backlog it is time to estimate. For the initial estimation choose from different Agile estimation techniques. You can walk through your backlog item-for-item and assign a Planning poker number or T-shirt size to each. For larger backlog it is more efficient to first cluster similar-sized items first, and then assign a size per cluster.
Again, the most important thing is to have the right people in the room while estimating. All of them. Also, print each backlog item and arrange it on the wall or table. A physical representation of the backlog works far more effective than a projected or printed Excel sheet. It really helps to identify relations and similarities between items.
Whether you do a project the Agile way or not, I strongly recommend to apply at least two different estimation methods. So, next to a T-shirt size based estimation, I would use a second estimation method, like an expert- or analogy estimation. This way estimating will take a day, or less.
The speed of time
The hardest step is to forecast the duration to complete the work. This depends on how much work can be done in week, your velocity. If you don’t have historical data yet, by far the best way is to learn the teams velocity. Let them realize a few stories from the backlog and learn how much they can complete. If this is not possible, let the team take example stories from different sizes and analyze them in detail. You can use the estimations of these stories to calculate the size of your complete backlog. Anyway use the Agile transparency to constantly monitor your assumed velocity. Also, as in old-school planning, calculate different scenario’s, assuming a range of velocities.
Conclusion: an accurate planning in a few day’s time
This article learns how to make a lightweight, though accurate planning. Using a story mapping workshop, an estimation workshop and some smart extrapolations, at the cost of only a few day’s time. There is no need to walk away from fixed date projects or mid-term planning requests. Planning is not bad. Use them to choose your direction, but be prepared to adjust your course.