Skip to main content

The "planning <--> implementation" balance

One of the great things about Agile is the ability to manage the expectations of stakeholders quite early in the development cycle. Likewise, from a business perspective: one of the great things about Agile is the ability to change requirements late in the development cycle.

When putting together an initial product backlog with estimates and detail. A certain amount of planning is done (whether this software product be a green field project or a slice in an existing project).

Recently I have found myself in several situations:

1. A situation where little planning had occurred and extremely poor estimates.
2. A situation where far more planning had occurred and not so bad estimates.

Likewise, my trust of estimates in the second scenario was greater than the first. Either way, what's important is to manage this expectation with stakeholders and make things clear. Telling stakeholders or your PO with confidence why you don't have trust in your own estimates may seem like a silly thing to do. This transparency is needed though and if reasons are given as to why, then you have fulfilled your task in the initial product backlog building.

From my own experiences I see a clear equilibrium. If more planning is done, then estimates tend to not be so bad. If less planning is done, then estimates tend to be poor.

Now it's hard to strike this equilibrium. Sometimes we are under business pressure, sometimes we are not allowed planning, sometimes we are allowed a lot of planning.

Usually when I don't have much time to plan, I not only have poor estimates but I don't even capture most of the work in the product backlog. As such, I find that the best equilibrium is when I have enough planning to capture most of the work in the backlog and not necessary have the most accurate estimates.


Popular posts from this blog

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.

from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

Context and agile practices

At times we have competing responsibilities - ship code or don't ship it because of a small edge case bug; put pressure on our team or make the business happy; coach our friends or write code.

This is a normal part of our everyday professional lives, and it's important to strike a balance that will help us in the future, but also deliver in the short-term.