Agile planning: Your estimates suck
Your estimates suck and they will keep sucking. If you spend too much time planning a release, you are probably wasting your time. Planning is guessing, so treat it as it is. Plan roughly and adjust those plans as you go. Use a task management app that embraces change.
Respect the iron triangle
When we plan a release cycle, we are guessing the scope (feature set) that will be achieved in a specific time by given resources (people). The iron triangle refers to the concept that at least one of these three elements: scope, time, and resources must vary, otherwise the quality of the work suffers.
Next time you hear a project manager brag about completing all features on time and on budget, question the quality!
Why quality can’t be compromised
Quality in software development refers to how well-written the code base is. It is a measure of maintainability, test coverage and how buggy it is. The lack of it is called technical debt. If you’re building a product that you are going to use/sell and maintain for a long term, those are things you cannot compromise on .
One may argue that your business model is selling cheap low quality products. For example, if you’re in the business of T-shirts and you want to manufacture low quality T-shirts and sell them for a buck each, it might be a sound business. However, if you want to apply this to software, you can sell a minimum low featured solution—not a buggy, unmaintainable one. Why? Because buggy unmaintainable code is very high cost on the long term.
Vary time, resources and scope
Depending on your circumstances, choose which of the vertices of the triangle to vary. There is no reason not to vary more than one vertex. Actually, my preferred approach is to vary all that can be varied. Remember, rules that have no reason are just obstacles.
With Sandglaz Infinity, you keep your product backlog in an Infinity grid where each column represents a single release cycle. Start by customizing the default column time length e.g. weekly, 10 days, biweekly …etc. This is roughly how often you plan to release. The image below shows a backlog with a weekly release cycle. Jot down your tasks into their respective columns (releases) by guessing what will get done when.
Regularly adjust your plans by:
- Varying the scope: Adjust the amount of work to be done in the current release. With Infinity, you can move work in and out of the current release by dragging and dropping the tasks from one column to another.
- Varying the time: Adjust the release date. With Infinity, you can advance or postpone the individual column dates.
- Varying the resources: Hire more people or move people from/to your department. This is the most difficult vertex to vary, because of the human element. It takes time to find the right candidate and there is always a learning curve for people to catch up. Also, there are limits to this approach, nine women can’t deliver a baby in one month.
Many agile methodologies such as SCRUM and XP advocates time-boxing—varying scope only. If you are new to agile and are used to long release cycles, it might be a good approach to enforce shortening your cycles. Though it’s counterproductive to be rigid with your process, so keep an open mind to varying the other vertices as you get accustomed to small releases.
Breaking a release into two
The more frequent your releases are, the better. So you should almost never merge two releases into one . I’ll discuss the benefits of frequent releases in a separate post.
There is often a use case for the opposite; breaking a release into two. You can find yourself in the middle of a release and you have enough stuff to be pushed to production . Then stop, release and continue. To split a release with Infinity, click on the column header and click split.
Like what you read? Sign up now.
 There are rare case when you might chose to build some technical debt for a hard deadline (a random date blurted out by management does not qualify) but you will need to pay off that debt right after— never accumulate technical debt.
 If you do run into a situation where you need to merge the next release with the current release and you’re using Sandglaz Infinity, just set the end date of the current release to the end date of the next release.
 For example; recently we concluded mid-release that the best course of action is to upgrade Rails before completing feature X. Upgrading entailed a fair amount of refactoring and testing, and once it was done it was a good point to release to production.