Is there an alternative to planning and sequencing work in software?

The many facets of sequencing work, forecast instead of estimate

Context

Many companies nowadays plan quarterly OKRs or biannual big releases, they may be releasing software everyday, several times a day, but they don't do big marketing efforts of new product features or deals every day, they tend to cluster advancements to make it easier for the public to grasp and adopt, what we call general availability.

This doesn't mean that at the beginning of the work of these quarterly/annual projects all the work is apparently known and dependencies are mapped upfront.

There's more than one approach to plan and sequence work. A lot of "professional" project managers refer to the PMBok as the guiding definition of what sequencing activities are, Gantt charts and estimates come into play. On the other hand, Basecamp and others propose to have focus cycles of a few weeks, where the target is one interesting bet and we keep working on it during the cycle. This short project is evaluated at the end of the cycle and maybe iterated.

Enter probalistic forecasting

The book by Mattia and Chris on team metrics for business decisions is worth reading, if you want to visualise forecasts before reading the book make a copy as I did of their spreadsheets and input the number of stories, days of work or similar to get a taste of the approach. Use whatever you use to measure the actual work not the estimates.

We are not trying to set on stone all the constraints at the same time, but to isolate the problems and try to answer:

How long will it take to complete? This is a look-ahead indicator, assuming the pace of work is maintained, how much would it take to end. In this example, the project would take some additional sprints but we don’t put a date set in stone, similarly as we would do with older techniques such as PERT.

In this example the project will finish by the tenth' sprint, looking from the sprint 6. A sprint is a timebox where you count finished stories.

Tweaking parameters

If we discover stories and bugs faster than we fix/close them, we are not going to finish the project at all. It’s important to review why we keep finding new stories to do or what root causes of tech debt cause our bugs to resurface.

Dealing with perceptions

Forecasting helps us to deal with our past perception whenever we review the plan. To me the most dangerous perception of all is the perception of being late/failing a level of produce set in stone at the beginning of the project.

It demotivates the team implying you're never going to reach the target, which we set without elementts at the begining. Also it can give us a false idea that we have time to procrastinate.

Exit criteria

As important as keeping ourselves focus, we need to be clear when to cancel the project. It can become a drain of energy and money to keep prolonguing the project without enough feedback on our metrics. ShapeUp proposes a rather intense clean cut on the cycles to avoid projects growing too big without enough traction.

We need to ask ourselves what happens if we are later than X? What are the consequences and trade-offs. This is better to discuss in a pre-mortem of the project to make sure we know if the project is alive or dead when executing it.

One of the typical questions when planning is around what to do first want to do next and so on and it's important to have the principles there to make some decisions. These principles work best when set around the metrics we want to influence.