Timelines and Due Dates in Software

Timelines and due dates in software have come to be how we measure progress.  They are how we know when we have completed the work.  But the same way agile processes changed many parts of the SDLC, could they help evolve timelines and due dates?  The same way agile attempts to address requirement gathering, it addresses timelines and due dates.  Agile focuses on delivering of the right thing, more incrementally.  When working incrementally, the priority becomes more important than timelines and due dates.  

Work off prioritized tasks and products in software.

By working off priorities, I am meaning working from a prioritized list of features, products, or work tasks. I would make the case that working from a well ordered list still meets due dates and timelines. This can happen as you still work first things first. With most work, you don’t have an accurate sense for the timeline to completion when you first start the work. You often find out more once you have started the work.

Of course, work items have due dates. Work has to be done when it has to be done. When items are due should be used in determining priority though. Due dates need to be used to drive where you rank work items in the prioritized list. By working off priorities, you save much rework. As with fitting work to timelines, you are constantly figuring out new timelines of all of the varying work. That work is constantly shifting as you do the work, as you figure out new things, and as business shifts. By working priority, you don’t waste effort that is spent on timelines that only have to be continually reworked. Instead, focus on when something has to be done, and align priorities to match that. Then work the priority list.

2 examples of working the priority list over timelines and due dates.

The large work effort where you create multiple deliverable dates, milestones, and an ultimate completion date. After this, you have other projects that depend on the first. When finished, they can begin, or maybe continue. When one is delayed, others are delayed. The large work effort is never fully understood up front. It will always have unknowns. They only vary in severity and cost. Those unknowns have the potential for changes to the work, which require changes to timelines. Which shifts everything coming after.

Working towards priority on large work effort items, you can still get a sense for when things can be completed. You can’t do this accurately before starting the work though. Instead, you start top priority work, and once you are far enough, you can then accurately predict some dates. Which also lets you know when you might start the 2nd priority, etc etc. Work the top priority item, as your focus to be done as best and as soon as it can be. For larger teams, priority can also help determine how many resources will work the item.

Use agile priorities over timelines and due dates in software.

Working on items using the priority over a timeline is more of an agile concept. It is also a product mindset, vs traditional thinking and methodologies. If your organization truly wants to improve efficiency, shift away from timelines. Use processes that deliver the best work on the top priorities first. With this you will find better success and less wasted time. Timelines and due dates can be a thing of the past. Replace with priorities, and work those priorities diligently.

Further reading:

Here I dive into the concepts of the Agile Manifesto. This is continuing the discussion from its first part. Exploring Agile Further – Part 2

Why do agile teams and their stakeholders require trust? Here I discuss the importance of trust. Building the Trust in Agile Teams

And of course, the Agile Manifesto.

Leave a Comment