On Forecasting
In an Agile organization we find our stakeholders often seeking some understanding of when a work product will be “Done”. We could be talking with our Product Owner about any kind of Backlog Item, be it a User Story, Defect, new Feature, or even a full Epic.
So what is a Forecast? At any point while we are working on an item, we share our thoughts about when it might be “Done”, knowing that we probably won’t get it right, but with the intent of being reasonably close. Short forecasts should be reasonably accurate, and longer forecasts are expected to change. And that’s OK because we will maintain regular communication with our stakeholders and update them as the forecast changes.
Why Forecast?
Our stakeholders will look for estimates. They want to know when we will be “Done” because our work is a part of a broader plan. It is important for us to understand that overall business plan and where our work fits into that.
The plan could be simple. Forecasting for an individual User Story would inform the Product Owner when it might be ready for Acceptance, and allow them the opportunity to ensure they and any stakeholders will be available for a Review discussion.
The plan could also be much more complex. Forecasting for an Epic may be integrated with plans that tie in regulatory and other third-party reviews, marketing, and special events like conferences.
Always remember, when being asked for an estimate or forecast the first question should always be Why? so that we have an understanding of the context and are driving the right discussion with our stakeholders. We may even find that the stakeholders are not really looking for estimates or forecasts, but rather might be looking for something else entirely. And if the request was for an estimate (or worse, a commitment!) we should follow up with a discussion on Forecasting, and work with those stakeholders to help bring them along for the journey with us.
What are we Forecasting?
We may find ourselves providing many different types of forecasts for a variety of reasons, from small-scale forecasts such as when a Backlog Item will be ready for Acceptance, to large-scale forecasts such as when an Epic will be ready for rollout to customers. Our teams do not necessarily need to be providing all of these forecasts. We just need to be ready to address the stakeholder needs.
When can we start?
This has to start with the Lean philosophy of stop starting and start finishing. We need to take care to ensure we are finishing, as that is when value becomes real. So when we can start becomes a question of where the work is in relative priority, and when the other work will be Done. In Kanban this is a question of when there will be room in that workflow stage. In Scrum this is often a question of when the work will be Ready to bring into Sprint Planning.
You do want to understand why the stakeholder is asking this question. This may be a proxy for another question: when will it be done. If that is the case, tread cautiously and gently transition your stakeholder to that broader question of done.
In other cases the stakeholder may have other work that needs to be in alignment, either work they want to complete in advance or concurrent with this work. This can open us up to a very good and healthy discussion with our stakeholder regarding that broader plan, and how all of this work gets aligned. Take this as an opportunity to learn about the broader business context, what that other work is, be it marketing, compliance, regulatory, training, or work with other teams, and help them refine how this all ties together.
When will it be ready to test?
This one will often come as an internal team discussion, and can be a valuable thing to discuss during Sprint Planning, and for Kanban is something to discuss when we start work. This conversation can help raise healthy conversations on potential conflicts and blockers, availability of testing environments, and even risks on our ability to complete the work within the sprint.
When considering the answer the team must first consider when the work can be started, and of course consider the effort involved in getting the work to that stage, often outlined by the team as task estimates during refinement and planning. The team must also watch for any constraints that might delay the work, or even delay the ability to test.
When will it be ready to accept?
This is often an important conversation that your Product Owner will be interested in. Product Owners are often quite busy, engaging with SMEs and stakeholders on feedback and plans for the product. Having a sense for when work will be ready for review and acceptance will help them ensure they are available, and line up any SMEs and stakeholders they want to include when they review for acceptance. In some organizations this will be synonymous with UAT or user acceptance testing.
As with the question on when the work will be ready to test, the team must consider the priorities, efforts, and constraints involved in bringing the work to this stage.
In Scrum, the team should strive to have the work ready to accept as early in the Sprint as possible. We should take care to watch for any forecast that suggests the work would not be accepted before the end of the Sprint. Should the team come to such a forecast, the team should have an honest conversation with the Product Owner, consider adjustments that might allow the work to be accepted in-Sprint, or adjusting what the team is bringing into the Sprint.
When will it be done?
This is perhaps the most difficult question, and is where the Why? is the most important question. On occasion this may refer to the team’s Definition of Done for a backlog item, and we’ve already touched on when an item will be ready to accept. More often, this question is focused on when the work will be ready to put in front of customers, and here it is also critically important to recognize the scope of work being discussed, be it a User Story, Feature, or Epic.
For smaller scope, you often have to consider what is involved between the point where the User Story or Defect is Accepted, and when it is actually made available to the customers. There may be many reasons for a gap. The Product Owner themselves may choose to hold until there is enough work ready for a release, or there may be other business or systems constraints, such as training schedules and standardized release schedules.
For larger the scope, then more complex the business plans are involved in that question. And also the more complex the answer. Have patience with your Product Owner and stakeholders, work closely with them to understand the business context, to understand and refine the actual need, and help them understand what will be involved in every step of the work. Bring them along for the entire journey, every step of the way, and work with them to continuously refine the scope and details of the work, and provide refined forecasts.