Skip to main content

estimates and forecast versus waste

Last post 06:22 pm March 11, 2020 by Laurent VIDAL
7 replies
09:23 am March 10, 2020

Hello,



Currently we have all the epics estimated because our PO needed a forecast range for the end of the project, which seemed alright.



I was wondering about waste. Because at the beginning of a project, the more we estimate, the more we are in the cone of uncertainty, because we know less about the product.



So are there some logical tools/facilitating techniques to help reduce waste, by deciding how much we can estimate, before being reasonably sure that we are too much estimating/refining.

 


10:02 am March 10, 2020

I believe that, more often than not, estimation at a large scale is waste. Consider your first example - estimating epics to determine the end of the "project". How do you know that what you have defined in your epics corresponds to all of the work needed to conclude the "project"? How do you know that you actually need to deliver all of the work defined in the epics to meet the objectives or goals that the "project" is supposed to achieve? In domains with a high amount of ambiguity and uncertainty, you don't and you can't.

Estimation in the small - at a refined backlog item or task level - can be more valuable since the work there is less ambiguous. Personally, I tend to favor not estimating since it's time that can be spent either discussing and understanding the work or executing the work. I have worked with teams that do find estimation a valuable activity since it can highlight cases where the team may not have a consistent view on the scope of work or the effort needed to get it to completion.

As far as reducing waste, I would emphasize limiting estimation to what is unambiguous. What that means varies for your organization. For example, if your teams are also addressing operational issues in addition to ongoing development, you may be able to provide ideal estimates for the development tasks but would struggle to provide completion dates since operational issues are often unknown (but there are techniques to model them based on historical data). It's very context-sensitive and I don't have any good rules of thumb at this point, other than driving estimates to the small or removing them entirely. 


11:28 am March 10, 2020

Currently we have all the epics estimated because our PO needed a forecast range for the end of the project, which seemed alright.

Since Agile is based on empiricism, what do you think about the likelihood of change in your project strategies and PBIs ? If they change then what do you think estimations accumulated for you?


12:23 pm March 10, 2020

The only purpose of estimation is to help a team to get its arms around how much work it thinks it can take on. All other estimation may be seen as waste.

So, why did the PO "need" a forecast range for the end of the project, given that he or she is interested in maximizing the value released each and every Sprint?


02:52 pm March 10, 2020

Based on your statements it seems that you have estimated durations for each epic.  This sounds very much like a waterfall project management activity. The only thing missing is a gantt chart.  

PO needed a forecast range for the end of the project, 

I get the need for a forecast but as with any long term forecast it is most likely going to be wrong.  For illustration purpose I always go the forecast that everyone uses, weather.  No one expects a long term weather forecast to be accurate but it can be good enough to develop long range plans. It is also understood by all that those longe range plans may change based on the revised forecast as time gets closer.  People only really expect a weather forecast to be accurate if it is for the next 4-6 hours.  And even then it often is incorrect. The weather forecast is updated constantly based on the current conditions. 

I will remind people of this analogy every time someone asks for an estimate to use for anything that is beyond the current Sprint. 


08:33 am March 11, 2020

I will add why the PO need a forecast range. It is to see with marketing department, up from when to start an online campaign of marketing on the new functionalities. You know sometimes before selling to the market, the marketing can use some technique like teasing. The marketing need to know roughly if the MVP will be finished before a given date, so that they can advertise. 



For example, let's imagine you are working on an embedded software for BMX. The marketing would want to know if reasonably, you will have a MVP of the software before advertising. The scope of the MVP would be negotiable, so the PO can set the most valuables features for the MVP. The PBI, order will change according to the market and all. Let's say you have a partnership with with some competitor Mr Great champion. The marketing will ask do you think it is reasonable to ask him to advertise on this race, or is it not possible and we have to postpone to another big race? Because the advertising cost money and takes time before being effective. So the PO will be the link between the team and the marketing team and therefore will need to know a range/ rough estimate to say yes or no to marketing.



And that was my dilemna to advise the PO, as he asked my advice, to where to put the cursor: estimate to give the rough estimation of yes or no, so estimating the remaining work for MVP to be in phase with marketing

AND the waste for estimating the work, because not all will be done and there will be some modifications



What are your thoughts about it?


03:46 pm March 11, 2020

Look into Monte Carlo analysis.  You can use the technique to forecast a future date to a percentage of certainty using existing data.  So start working on the problem, deliver a few increments, then use the Monte Carlo formulas to forecast future dates. 

Oh and the Monte Carlo simulations should be done without the use of estimates.


06:22 pm March 11, 2020

I will look into it. Many Thanks to all for all the advices and explanations :)


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.