​When planning for a milestone such as a release or a development finish, there are several approaches we can choose from. A traditional (and often intuitively chosen) approach is to try to predict and fix all the project imperatives. What does this mean?

As a countermeasure to reduce the number of unexpected events at the beginning of the project, it is common to make a detailed plan months in advance and expect the development teams to keep it.

Let's say we want to do a major release of our software. The product owner and the stakeholders make their expectations about a release date, the content (scope) it’s going to include, and the cost. In the best case scenario, their expectation is based upon a discussion with the development team.

The development proceeds and the release milestone approaches. More often than not, the team encounters unpredicted problems and some of the features are delayed. As the release date approaches, it becomes clear that the release plan is endangered. The team starts to get anxious. Then, shortly before the release date, it is evident that not all of the planned scope is going to be finished. As a result, the date gets postponed by managers with the hope that the remaining scope will be finished on time.

Moreover, additional requirements from the stakeholders arrive and the product owner wants to include them in the release to gain positive perception. The release has already been postponed once, so it would be great to overperform this time. As it usually happens in development, fresh bug reports arrive. Let's include corresponding fixes in the release too. A vicious cycle begins.

The point is that the more a release keeps getting postponed, the higher is the temptation to include additional content to make up for previous disappointment. Usually, a release is postponed multiple times and gets delivered weeks or months later with a great deal of nervousness.

What helped our teams in such situations?

Back to the basics

The first thing we hear when you learn about project management approaches, is how the combination of time, cost, and scope work together. The traditional approach is that in the planning phase of a project, it is decided what functions we will create, how much it will cost, and how long it will take. As I covered in my previous posts, I believe it is a futile effort to attempt to make an exact determination of all of the three project imperatives at once as reality rarely follows them in the long run.

When we define a fixed scope, fixed timeline, and fixed cost, there is virtually no room for flexibility if something goes wrong. From my observations, the effect is usually that in the (probable) case of unexpected problems, it is the quality of the delivered scope that gets sacrificed. In other words, it is an attempt to make the scope somehow flexible by re-interpreting its definition.

This usually leads to the project manager trying to negotiate a later time for a handover (or release). There is a tendency to check off as many items of the scope list as possible, so that it looks good in reports and on paper the project can proceed to the next phase (and possibly allowing for a payment milestone). But under the hood, shortcuts were taken and oftentimes the pressure to deliver something comes at the cost of the software being defective and half-functional.

In scrum terminology the scope items are not done. There is a technical and/or business debt. Contrary to the definition of done, there is still known work to be done on these items.

The costs for paying off the debt are considerably higher than the effort necessary in getting it right at the first go. In many cases, it also means that nothing can be released due to numerous defects. The whole package remains unacceptable.

Agile approaches try to keep one of the three imperatives (scope, time and costs) flexible. We have a given team with a certain development capacity. That team consumes a predictable budget over a given period of time. What options do we have?

• Team capacity (staffing): affects the throughput over time. Changing it influences the rate at which budget gets consumed and scope gets developed. In this article I assume that the team is naturally using its resources effectively and attempts to improve its performance over time as it matures.
• Development duration (time): affects how much scope can be delivered with a given capacity and lets us cap the invested budget.
• Scope: changing scope will affect how long a given team consumes the budget.

So if we have a specific budget we need to invest, we can set a suitable team, calculate how long the budget will last, and keep the scope flexible. Or the other way around, if we want a precise scope to be developed, the timeline becomes the bumper. Also, the team size needs to be chosen adequately. We need to be able to supply it with high value business requirements meeting the definition of ready.

How to combine time and scope

Unless we are in a very rare case when the product aspects are well predictable (process-like activities), we must accept the fact that we need to prioritize the project imperatives. In my experience trying to juggle both scope and time at once usually leads to a lot of confusion and it often sabotages any rhythm the team may have. I believe prioritizing one over the other is the way to go.

On our projects we usually keep the team capacity at a reasonable level and then prioritize time over scope. That means we set a particular milestone in the calendar and concentrate the activities into making it happen. The scope is the flexible element.

Let's use an example. The product owner wants to make a release of an update on the market. He deems that it’s worth doing it a month from now because that will bring a considerable improvement to the user and will create a positive perception.

The product owner and the team make their preliminary prediction about what backlog items they expect to deliver. The team spends that month working on them. As usual, they discover considerable complications with some backlog items along the way and major defects are also reported from the users. Then it becomes clear that not all of the originally expected backlog items will get done by the release date.

The development team, together with the product owner re-prioritize the backlog to incorporate these new findings. It is decided that the resolution of certain bugs would bring considerable value. Problematic backlog items are put off, so that the team does not spend effort on something that will probably not be finished. The team focuses on the sole goal of making the product releasable at the given time. They are not obsessed with the necessity of delivering absolutely everything that they originally thought. Functionality that will not be included in this release will be contained in the successive one.

Figuratively speaking we need to draw a horizontal line in the backlog. There are two options for where to draw it. It's position is either fixed and the exact development duration will be adjusted, or time is set and the position of the line in the backlog can be adjusted along the way - it floats.

By keeping the backlog constantly refined, well prioritized, and the backlog items as atomic as possible, we are maximizing the chance that what falls over the line isn't vital.

In the example above we used a release as a milestone. But a milestone can be any other critical event - such as consumption of the project's allocated budget.

It sounds easy, but...

This idea is nothing revolutionary. But putting it into practice usually includes avoiding a few frequent mistakes:

• Avoid stakeholders from expecting strict time and scope fixation. It takes effort to explain that there always needs to be an approach to minimize risk of critical stuff falling over
• Avoid stakeholders from putting you into a situation where everything is equally important. It is the job of the product owner (with the help of the scrum master) to educate them about this.
• Don't be tempted to postpone the release milestone just a little so that you can fit in that one extra valuable item. It's better to set a regular schedule for releases and be safe in the knowledge that it won't take long before the next release.
• Don't juggle with both scope and timeline at once. Prioritize one over the other.
• Don't cling onto past predictions. The situation always evolves and rather constantly evaluates if the prediction is still valid or not.
• Don't get caught up in details. Use the dailies to take a step back and see how the team is progressing towards a goal and if there are any new obstacles in the path.

Psychology plays a major role when things don't follow the budget - scope - time triangle. But it would be naive not to proactively take steps for when it happens. Deciding on a general strategy - whether to fix time or scope - takes a lot of weight off the team's shoulders and makes development much more predictable and manageable. So always think about what can be sacrificed from the original predictions if things go wrong.