“When will it be done?” is a question that a surprising number of IT professional struggle to answer with certainty. This is surprising to me, because in many situations it is reasonable easy to come up with a suitably certain answer. Yet no one has done so. Instead they are pushing ahead with little to no understanding of whether they are on track to achieve their goals. This blind faith is admirable even if misguided. This article aims to show you how to answer the question of “When will it be done?” with a suitable level of certainty. Doing this allows you to harness and direct that faith to achieve your goals sooner or better.
To answer the question of “When will it be done?” there are several pre-requisites; none of which are difficult when working in an agile manner.
Your Work items need to be potentially shippable increments of the product. They need to be vertical slices that ideally deliver some business value. Splitting up your work in this way means when something is “Done” it is really “Done”. This approach reveals the hidden work to achieve our goals. This article will not delve into how to accomplish this as there is plenty of existing literature on this subject.
We also need to know:
- How much needs to be done? Aka. Work items to do.
- How much has been done? Aka. Completed work items.
- How fast are you completing work? Aka. Rate of completing work items.
The following sections will provide more detail on how you can answer these questions.
How much needs to be done?
The biggest hurdle I see to people answering “when will it be done?” is that they don’t know how much needs to be done, and they don’t know that because they don’t know what “it” is. The excuse of “we will know it when it’s done” often comes out, which does not help anyone. Instead you need to become comfortable with ambiguity; and focus on the reducing the unknowns that get us to a point that we can develop an initial high level view of what “it” is. Often you can develop a forecast with what the project team currently knows about “it”. Early on this forecast will be less certain than you want; however this forecast will be refined and improved as the project team learns more by doing.
How much you know about “it” should guide your choice of determining how much needs to be done. To figure out which approach to use, please determine which of the following three situations you are in.
Situation 3: What needs to be done to achieve “it” is unknown and currently unknowable. Currently we cannot write out a bullet point list of what needs to be done; even at a high level. There are multiple significant unknowns, multiple risks, and likely more risks or issues we are not even aware of yet. You are deeply in “Research”. Suggestion: Don’t use forecasting yet. Instead focus on reducing your unknowns, reducing risks and doing spikes/investigations. Your aim should be to get to Situation 2.
Situation 2: What needs to be done to achieve “it”, is only understood at a high level. We can write a bullet point list of roughly ten or more work items that comprise “it” Those work items may be very large, this is not a problem. Suggestion: Determine how much needs to be done by elaborating a sample of work items. This means: 1. randomly select three of those ten plus work items. 2. For each selected work item hold a workshop with a cross functional group from your project team. In the workshop split up the large work item into smaller potentially shippable product increments. These need to be close to the size of work items that your team regularly completes. 3. All of these smaller work items need to be estimated. The result is that you know the size of three of the large work items. Importantly this size matches up to the way that you measure completed work. To determine how much needs to be done average the size of the three elaborated work items and use that size for the remaining unelaborated work items. This provides a roughly estimate of the total work be done.
Situation 1: What needs to be done to achieve “it” can be known with some certainty. The Product Owner has a vision for the Product; the technical people have a rough understanding of how they could build it; the ‘leads’ have a reasonable yet incomplete understanding of what “it” is.
Suggestion: Hold a half day User Story Mapping workshop with the whole team. During this workshop:
- The whole team will form a shared understanding of what “it” is and is not.
- The work will be split up into work items of a size that your team regularly completes.
- All of the work items will be estimated.
Having done the hard work of understanding what “it” is, determining how much needs to be done can easily be achieved by summing up the size of all of the work items.
How much has been done?
This is simply a matter of adding up the size of the work items that we have completed that directly relate to “it”.
How fast are you completing work?
On average how much work are we completing within a cycle? If you are doing fortnightly Sprints and using Story Points; this question becomes “What is our Velocity?” or “What is the average of total Story Points completed within a fortnight?” If you are just starting out you may have to initially guess this figure. As you complete more sprints/iteration this figure will become more realistic; hence improving your forecast.
Create the forecast
Now that you know how much needs to be done, how much has been done and how fast you are completing work; you are ready to create a forecast. It is the forecast which will answer the question of “When will it be done?”
Example burn up chart showing forecast completion 1 day after the target release date.
For your first attempts at forecasting I recommend a Burn-up chart. A burn-up chart has work on the X axis and time on the Y axis. The burn-up chart is updated each unit of time (usually Sprints); providing a more accurate forecast each time it is updated.
The burn-up chart above shows five key pieces of information:
- The total scope (how much needs to be done) Purple - solid
- A projection of the scope into the future (what is the average increase in scope) Purple - dashed
- The total done work - Green solid
- A projection/forecast of the done work (based on your expected velocity) – Green dashed
- Where the two projections cross over, tells us the expected completion date - Orange
Please contact me should you want assistance in populating or interpreting your burn-up chart.
NOTE: Forecasting using a Monte Carlo simulation provides a richer and more realistic forecast; however they are complicated to set-up, and will not be addressed in this article. Please contact me if you would like to start using Monte Carlo simulations.
Example of a completed project. Sprint review on Sept 1 indicated we were way off track. Note the large de-scoping that occurred shortly after and the increase of delivery from hiring one more experienced developer.
Forecasting should not be a one-time activity; while it useful to do it once, its true value comes from continuous updating the forecast and holding regular conversations about what the forecast is telling us. For a Scrum team you should update your forecast at least once a Sprint.
Continuous forecasting will catch situations such as:
- Our recent reduction in velocity has pushed out the expected completion date by 5 weeks.
- Adding those new features has pushed out the expected completion date by 7 weeks.
- Each sprint we are finding more new work then we anticipated, at this rate we will never achieve our goal.
If you started your forecast while in “Situation 2” there will come a time where the team has learned enough to move to “Situation 1”; this is a key time to update the forecast which could shift significantly. The earlier you can do this the earlier you can hold the potentially difficult conversation with stakeholders about when they are going to obtain their objective.