Watch the Video
Listen to the Audio
When your forecasting is on point you can practice smooth product planning on the team level and with your stakeholders.
Getting to this point is often tricky and for some teams the work to get there and the perceived implications of what might happen when they give timelines can be off-putting.
Firstly, let’s appreciate that as a product team we’re often in interdependence with several other parties. Everyone is trying to do their job and wants to serve the customers.
When we have a reliable handle on when we can get things delivered by everything around our product regarding delivery gets a lot clearer.
This is a sizeable subject. There’s a strategy for getting from not having a handle on dates, or being in a place of promising dates and not meeting deadlines to an ongoing planning dialogue using your delivery data for smooth forecasting.
In this episode I’m covering the overarching approach and considerations to get on the forecasting bandwagon.
To support you on the path, you might like some additional guidance. Here is an episode from the “Power of Three” series on what makes a healthy Product Backlog.Monthly Learning Club session, titled “Getting Forecast-Fit in 90 Minutes”.
Listen on Spotify
- "Hello, hello.
When a stakeholder comes along and asks you, where are you with a delivery of a certain chunk of value? How do you respond? How can you get to a place where you can actually provide a useful timeline in your product development? This is the focal point of this video. Stay tuned more after this.
Hello, welcome, welcome, welcome. My name is Georg Fasching. I speak to you from a background of about 20 years in product development. 10 years, pre agile 10 years leveraging agile and all sorts of new approaches to handling knowledge work, working with some great companies and some great people.
And if there is one question that was always asked, it was always when can I have it? So how do you respond as a team?
If you're already really superb at forecasting and product planning, let me know in the comments below, what you're doing to stay on top of these things and what it took to get there. If you are not quite there yet, then this video will hopefully help you make some significant leap forward.
Now, when I transitioned from pre agile work to leveraging the world of the agile working practices, I have reviewed also how we go about timeline planning. Now, while I think that in traditional IT project driven product development, there is an obsession with dates and deadlines. I have learned why it was always so difficult to ever get close to them, but that was because we had it upside down - the way that we went about the work. And we were not cross-functional. We did not do things across the whole technology stack every step of the way and so on and so forth. But that then came with also a sort of shift going to agile ways of working, when doing it properly, actually gives us a lot more opportunities for much more accurate timelines than the ones that we were planning and never hitting without agile ways of working.
Yet I still see several teams out there at different companies that are very hesitant to even think about getting to a place where they can provide timeframes and timelines.
And any idea for giving some sort of a forecasting ability is met with a "yeah, let's not go there yet, lets not go there". But it's actually quite simple to get there. And before we talk about what it takes to get there, let's work on how we even approach the subject of it being valuable. So where do the requests for timelines come from? Well, it comes from an environment that needs some idea of when things are coming so that we can align other activities around it.
In most organizations, the marketing of a product is not done by the team directly. There is another department or another team that handles the marketing. Well, in order to plan the campaigns, plan whatever marketing activities are out there, they need some sort of input into the timelines. So that's quite important because when we add significant chunks of functionality, or we even have the first launch of a product. Then we need some input into the marketing time plans, because this product will not be the only one that is available there. Then another area that will benefit from timeframes and timelines is sales.
So depending on what your product is, but it might have to be sold on a B2B basis. And ideally you already have a collaboration with the sales departments. So your product is not sold over capacity, or certain features are in promise that are inconceivable or the timelines aren't there yet. So when it comes to collaboration with sales, then product road mapping is a really, really important tool to align around expectations. And if you want to do a product road mapping, right, you should have some idea around timeframes and timelines as well, and so on and so forth.
So as long as you are a product team within a wide organization, chances are there are going to be some others whose work you rely on as a product owner or product manager.
And you need to have a way of talking about timelines. And if you ever want to be able to give anything that is not worthy, you need to come to a place where your team is able to forecast. And when I talk about forecasting and dates and deadlines, there are some dates that you might want to hit, and those should be dates that are either set by regulators. And you may not have any influence over those dates.
And if it's something new, you might have, I got to work at a financial organization many moons ago, where we were working closely with the regulator, because it was about a very, very new way of financial services or where a new way of payment services. And they were learning about it as we were learning about it. And it made good sense to collaborate on deadlines, but most of the time you don't have influence over regulator dates. So those are definitely some that you want to work towards and hit. And ideally, when you're planning for your product, you want to be able to meet the regulation way before the regulation comes to pass so that you account for learning along the way and emergence that is bound to happen anyway. So regulators is a great example.
Industry events are another great example. So you might be in an industry where there are some key annual events that are useful to hit,
and you will know which of those are for your particular context, and they have certain dates. So for example, there is the consumer electronic show every year, beginning of the year. And when you have a new product or some big announcements for your product, it is, it might be useful to have those ready there, and you need to be able to plan towards that and so on and so forth. So, if the argumentation around the value of working towards timelines is already sort of common knowledge, and I'm sort of preaching to the choir, then let's slowly move on to the next one. But in some organizations, there is perhaps not much appreciation of why you even need to bother with being able to forecast for your product. Hopefully some of these examples have shed some light on why that might even be necessary.
Right, so moving on to how you get there. First of all, there are different levels of forecasting that you might want to look at.
If your stakeholders are pestering you about specific features, then it might be useful to elevate the conversation to strategic goals and larger value chunks that you might have on your product roadmap rather than discrete, specific small features that are in there. Depending on the nature of those features, it may not really be worth the time of the conversation to even track those small things. So thinking back to, well, what would this feature do for some strategic objective, some strategic goal that exists for the department to elevate the conversations to a more strategic level, and then coming back again to skilful product road mapping, that's always the way.
Now for those teams or representatives of teams that watch this, and you are now realizing that for your team, for your product, there is no product roadmap, might be a good place to start and think a little bit more ahead. Otherwise, the work that you do is very tactical and you're working from one iteration to another, or you're using Kanban from one product backlog item to another and it's very difficult to actually appreciate where this is all going. And if we don't have a sense of where it is all going, then the motivation may also not really be as strong as it could be.
So imagine you had a really strong compelling product vision, and you had a product roadmap that gives you a very clear guidance on what the next big chunk is that you're working towards as a team. And that gives you a much better goal to work towards as a team. So for product roadmapping to get started from no product roadmap to a product roadmap before you even have any lever or any grasp on your forecasting, an easy way to start is what are we gonna do now? What are we gonna do next? And what are we going to do later?
And again, chunk the items that you have in there onto specific sets of features that have meaning and can be put onto a roadmap.
And the now next to the future, the now might be the next month two, maybe three. And the next would be the three to six months after that. And then later would be that. So that would be step one on moving from zero roadmap and zero looking ahead and forecasting to the next best thing, which is now, next, later. I've already associated some timeframes and timelines with that. And over time you will get closer to that and better at that.
And now comes the real kicker. One of the key concerns about moving from zero forecasting to forecasting that holds teams back, is that yeah, but we don't know anything about our ability to forecast. It's going to be wrong. And let me tell you one thing, it will be wrong and that's okay.
When you get started with forecasting, it will be wrong. What you're going for is accuracy within a certain variance.
And when you start doing this, then the variance will be bigger. And over time it will get smaller. So in the beginning it will be wrong. The objective is not to be 100% precise. The objective is to get more and more accurate. We're not forecasting for precision, we're forecasting for accuracy because this is complex adaptive work. And in the beginning you will be wrong. So don't aim to be perfect first right, aim instead to be less wrong over time.
That should hopefully alleviate a lot of the concerns already. Now, when we are looking a little bit further, where are we going when it comes to improving your ability to forecast? Now, what do we need to forecast? We need to have a sense of how many user valuable items we can create in a given planning period. I've already done more content on product backlog refinement. The last one was just last week. So in the playlist, if you check, I can also link it in the thing. And then the card up there, what to do to improve your refinements and some tips and tricks you can use there. So you definitely need to do that cause otherwise it's not going to work.
You need to invest the time to refine together as a team. And this is part of the natural work of product development.
You're building holistic product knowledge as a team together, and you're refining items, breaking them down, making them smaller, making them more defined, more well understood, clearer, and ensuring that you have everything that you need in order to deliver them in a given planning period or in a given sprint. And when you do that and you get better and better at that, you will then also improve your ability to pull in an appropriate amount of items into any given planning iteration, into any given sprint.
So again, the first time you will unlikely be on point, but you will get better at it time and time again. And the hardest part is to get started. And the first few sprints, the first few iterations will be difficult as you learn how to refine your items, how to refine your product backlog items, and you will get better at it over time. So in the beginning, yes, it may very well be painful, but it will get better and easier the more you practice together as a team. Refinement is a team sport, and it is a skill that you practice together as a team. And there are many tips and tricks available that you can use in order to do that.
So this is part of the work that you need to do in order to move into a place where you can forecast better.
And once you have an understanding of either, if you choose to do estimation by story points for relative levels of effort, then that will be the numbers that you use in order to also forecast. If you choose not to, and you just simply use new product backlog items and a number of those in any given sprint or planning, iteration, so be it, it doesn't matter. One figure is needed in order to put you in a place where you can forecast. Some teams, then say "yeah, but we don't like those number things. We want something a bit easier to adopt for some reason. And then we have small, medium, large, which is another method of estimation." Yes, you can do that, but you still need to figure out how many of those, and in which constellation you can do inside the sprint, do you only want to do small items in every sprint?
Okay, do you want to have a mix of small and medium items in the sprint? If so, what is the mix, or the mixes that you are willing to accept? How many mediums and how many smalls are you willing to take into a sprint? These are all the relative terms, but it doesn't feel appropriate to even have any large items in a sprint, that's just too high a risk to take, you should break those down and prefer to have small items and the odd medium item in there, if you will. Even with that, whatever the means is that gives you a handle of number of items or scale of items per sprint or per planning iteration. That is what is then used in order to forecast.
In the refinement video, I also talked about that you not only want to refine items for the next sprint, but look a little bit further ahead.
And once you have just enough for the next one, then you zoom out a little bit and start to break down the other items in a product backlog. And by doing that zoomed out a little bit, you can then also check if you have a healthy product backlog, there shouldn't be any placeholders or rubbish on there from the old ages, you want to have something that is actually meaningful in your product backlog and then look how many items you have and use that in order to then say, well, in order to go to this level of the product backlog, which would give us the next chunk on the product roadmap, then based on our throughput as a team, we were likely to hit that sometime between this timeframe and that timeframe, okay?
The more you do that, this is an iterative process, the more accurate you will get. So if, based on where you are right now as a team, and you do this the first time, you're looking after the next roadmap milestone, and it's looking like you have one, two or three months left for this, come back to it in two weeks and update and update and update. So when you start to talk to your stakeholders about timelines, it's also important to take into account how experienced you are at forecasting with this particular team and start communicating in time ranges rather than an absolute dates. So this is how we go back to the entry point of this particular video. You want to be in a position where you're able to hit dates that are set by the outside world, that you have no control or influence over. So when you're working in a regulated industry, you need to hit regulated time dates. Then you actually want to be able to already meet the requirements way before that even kicks in.
So you need to prioritize your product backlog accordingly so even if something goes wrong, you know, and you're confident,
and your stakeholders can be confident that you are meeting that timeframe and the same thing with other industry events, where you have conferences. So those are the top strategies for moving to a place from where you cannot give any remotely reliable response to the query of when can I have it, or when will it be here, over to something that makes a lot more sense. So then, my key objective for this video was to perhaps alleviate some of the hesitancy to get started with this. If there is hesitancy and a worry about answering that question, then it is likely that you just haven't started yet with this particular practice. And that's okay. So in the beginning, just get started.
Don't worry about being precise, worry about getting more accurate over time and approaching it this way. And before you know it, after one, two, three, no more than three to six months, you should be in a great place. Keep practicing, keep iterating your plannings and make planning and this review a regular part of your process, and you will get better at it every single time.
And those are the thoughts that I wanted to share with you. If you do have any other queries about forecasting and planning, please do let me know and feel free to post any comments in here. If you have any requests for other topics, this week is product week. So everything will be product themed for two more streams, it looks like for this week. And let me know what else you want to have here. I am also considering doing interviews on this channel. So if you have any noteworthy stories or even any requests for guests for me to invite them on here, feel free to post that also, or get in touch with me over LinkedIn, if that works better for you.
So with that, I would like to wish you all the best for coming up with some absolutely smashing wonderful forecasts and improving your planning with that for your product craft. It's been an absolute pleasure sharing these thoughts with you.
So thank you very much for now, all the practice with your teams. If you did find something useful in here, please give it a like and share it with some friends who could do with some of these tips that you found valuable and consider subscribing for more and hit the bell for updates.
==end of transcript==