Release planning is largely an empirical activity. Capturing the requirements effectively is the first step. Capture the thoughts of product owner or client in a free flow, map them to user journeys and fine grain them to small requirement statements. Each of these granular requirements which can be expressed in a sentence or two will be the basic building blocks of the final product. It is popularly called as stories and getting them right is the first step of a successful release planning.

Visual triaging


Write each of the stories on to index cards or stickies, preferably colour coded based on parent features and put them up on a wall or a large table so that you can see all of them at once. This helps to see the spread of the requirements and allows to dive into deeper details for ambiguous entries.

If the ambiguity does not resolve with deep dives we quickly get the developers to do a spike (proof of concept) to validate our understanding. The proof of concepts have to be very quick but deep enough to provide us an understanding to estimate the effort involved.


When talking about sizing, people immediately try to force fit their stories into fibonacci series or arbitrary small, medium, large. Instead we need to create a real world analogy for sizing the stories as mentioned in one of my previous posts. The last few years I have been using Scooter, Car and Bus as my sizing references for stories; and as I expected most of my sizing meetings have shrunk to less than half of what it used to be when using fibonacci or t-shirt sizes. If you have outliers which do not fit in any of the categories we temporarily park that in a trailer or ship category if very large or in bicycle if it is too small. The outliers are revisited and the stories are rewritten to see how they can be fitted into the sizing slots. The very large stories always have been unpredictable and skew the time taken for a point metrics, so we have to break them before the end of the sizing phase.

Velocity estimation

Remove the sizing details from the stories, pick developers in a round robin fashion and let them pick what can be done in five ideal days. That is there are no meetings on that day, no holidays, high availability of all machines and tools, no dependencies.  The developers each should do around 5 iterations of picking stories and the result has to be captured like below.

Developer 1

Week 1 S,S,M
Week 2 S,S,S,S
Week 3 M,M
Week 4 L
Week 5 S,L

Developer 2

Week 1 S,S,S,M
Week 2 M,S,S
Week 3 M,S,M
Week 4 L,S
Week 5 M,M

When we collect all the developers’ estimate and average out, we will be able to come up with the ratio of S,M,L like 1:2:4 , 1:3:7 or anything but not necessarily fibonacci. If we had taken fibonacci there would be too many arguments whether a story is a 2 or 3, but we avoid that argument if we let the velocity estimate give us the ratio. The ratio then becomes the points for a size, if the ratio turns out to be 1:3:7 then our S is 1, M is 3 and L is 7.

Realism infusion

It is not possible to plan for work in ideal days; there will be meetings, holidays, sick time, vacations, down times etc. We need to account for those. If the velocity estimate which we can call it as raw velocity comes out to be 10 points per week then we deduct the appropriate numbers to get a highly probable velocity. Typically this works out to be around 70% of raw velocity but it purely depends on the teams.


Clients will always say that they want all the features they have envisioned, but there are many stories where an app ends up where most of its user use only the 20% of it, the remaining is a long tail with very little returns to the effort involved. The product owner has to come up with the must haves for an initial set of features. There are many popular techniques used, MoSCoW prioritization method is one that is frequently used. If there are many people who will prioritize then each of them should come up with their own priorities and the chief product owner takes a call with a common denominator. The explanation is simple but most of the clients struggle to come up with a prioritized list as the illusion is every thing is a priority.


The stories are sequenced against a weekly timeline put up on the wall or a large table. The stories are then picked up in the order of feasibility with priority given to difficult and important stories. This step will give us lots of options on the number of parallel streams of work that can be run, what are the dependencies between stories, the order in which the features can be completed, the team ramp up and ramp down plans. The kind of mix and match we can do depends on the granularity of the stories and the amount of dependencies between them.

After the last step has gone through few rehashing we will be able to come up with an initial release plan to start with, this plan should always remain as the reference and re-planning has to happen on a monthly or fortnightly basis to keep adapting to the learnings we get as move along. Many people treat the initial release plan as a sacred rigid plan but that was just a guideline to tell us how to approach development. It is a waterfall project if the initial release plan was delivered as is.

I was having a chat with an old time ThoughtWorks developer, the topic was trending towards voluminous work and long days at work. I interjected with the point that the developers should not be willing to work long and hard hours, instead they should be lazy so that there are better tools and automations coming out of them, rather than checking boxes on long todo lists for the day.

He thought for a while and then replied “You are right, the CruiseControl continuous integration tool was born out of laziness”. He went on to explain that one of the developers felt that it was too annoying to walk up to a computer, pull code out and run the build & tests. So the person put a build loop on that machine to do that task. Someone else put a web interface to it and there a new tool was born. It left a lasting legacy in the continuous integration space. (Cruise control home page).

Why do people relate long working hours to prosperity?

The industrial revolution required a good deal of unskilled labourers who were given instructions and repetitive tasks to be done. The more they do, the more money the company makes. So overtime was rewarded with more money and people tend to stay longer to get paid overtime. The invention part of automating the repetitive tasks were left to someone else, the thought of hard and long work is rewarding stayed on even though there was a chance of a new invention that could take this entire category of job away.

After many decades of advancements in the industrial space, automations have taken a majority of space. The place where the automation as of now is not able to get into are creative spaces or knowledge work. If a job requires more than few simple steps then it is beyond the mechanical skills and involves cognitive skills. The moment when even rudimentary cognitive skills are involved, then no longer any of those incentives and hour based pay work. It is explained well in the video created from the work of Dan Pink, the author of the book Drive.

Wisdom gets passed on through generations, bosses and workers alike, people were conditioned from the childhood that hard and long work is the only way prosper. When that person becomes the boss, demands the hours and when that person is the worker, obliges to it.

Programming is a step further, it involves complex thinking which requires us to bring deeper parts of our brain to work. Andy Hunt in his book The Pragmatic Programmer talks about L-mode and R-mode, which is about using our linear mode of the brain or the rich/random mode of the brain. Though there is value for linear mode, programming benefits a great deal from the R-mode. Staring outside the window, doodling, watching the fountain, a stroll could all be more productive activities than staring at the screen and furiously typing commands for long hours because new ideas pop out when you are least expecting and unprepared.

A programmer has to be lazy, should not jump into the task at hand instead approach programming with a mindset of ‘No code is the best code’. Laziness will make us look for to remove mundane repetitive tasks out of the way which will also pop up more creative ideas through R-mode. Workplaces should also help ease the norms of equating the number of hours in seat to productivity.

Push the problem out of your foreground mind, and just “hold it lightly”. Then go for a walk, etc. That’s when insights and breakthroughs come to me.— Henri Poincaré