Agile Estimation: The Art of Balancing Precision and Uncertainty – with Barbara Roberts

Introduction

Unleash the power of estimation with our captivating webinar featuring Barbara Roberts as she dives into the art of creating the perfect balance between precision and uncertainty. Gain invaluable insights and practical strategies to achieve accurate estimates that align with expectations and serve their intended purpose. Take advantage of this chance to elevate your estimation skills and drive project success.

Watch the webinar recording with Barbara Roberts today and unlock the secrets to effective estimation.

Video

Watch the video, download the presentation or audio, or read the full transcript of the webinar below.

About Barbara Roberts

With an illustrious 50-year career in IT, Barbara Roberts has witnessed remarkable transformations and played a pivotal role in shaping the first agile approaches in 1994, drawing from UK industry best practices. With her extensive expertise spanning diverse sectors, she guides complex corporate entities through adaptation in the modern era.

Barbara’s brainchild, Agile Project Management, launched in 2010, has achieved remarkable success, boasting over 200,000 accomplished exam candidates. Renowned as a sought-after speaker, Barbara captivates global audiences with her recent masterclasses in Australia, Singapore, and Kuala Lumpur, known for their refreshing blend of pragmatism and common sense.

Agile training

Agile, an iterative and flexible approach to project management and team collaboration, thrives in dynamic environments by focusing on delivering high-quality results. It emphasises frequent communication, collaboration, and incremental progress, allowing requirements and solutions to evolve through the collaborative efforts of self-organising teams.

Enrolling in Agile courses can significantly enhance your team by fostering collaboration and communication, increasing flexibility and adaptability to change, and improving overall productivity. These courses provide valuable insights and techniques for cultivating a collaborative culture, streamlining workflows, and effectively prioritising tasks. By embracing Agile principles, teams can better address customer needs, deliver faster results, and continuously improve performance.

Explore details with the relevant links below:

Agile certifications

In-house agile training

Agile consulting

Agile coaching

Transcript

Here’s the full transcript of the video.

00:00:03 Sevcan Yasa: OK, let’s slowly start.

00:00:06 Sevcan Yasa: So just to give you a bit of background, I’m Sevcan I’m the Marketing Executive for Knowledge Train, Knowledge Train and agileKRC are in partnership. Today we have Barbara with us. So, thanks so much for joining. This webinar is recorded so after the webinar, probably next week, you will receive the recording as well as the PDF version of the PowerPoint. Right at the end we will have a Q&A session. So, if you do have any questions, you can always drop them down or pop them in the chat and we’ll go over them right at the end. So, Barbara over to you.

00:00:42 Barbara Roberts: Thank you very much Sev. So, hello and thanks everybody for joining this session. It’s lovely for me to get the opportunity to talk about the two things I’m very keen on. One is Agile obviously, and the other one is estimating. It’s one of these things that everybody assumes people should know how to do, but nobody ever teaches you so. So, basically what I wanted to do with this session is talk about how estimation actually works, and if you’re wondering why me? Basically, I’ve been around doing Agile for forever since we decided it was before it was called Agile. I worked on rapid application development.

00:01:21 Barbara Roberts: I’ve been involved with Agile a lot and basically, I help organisations transform to Agile. So, I specialise in the complex corporate world, but I always believe, and I keep telling people that Agile is a lot about common sense and it’s about being pragmatic. It’s not about following a rule book and I’m lucky enough to get invited to talk all around the world in the last three years, mostly from home. But before that I’m travelling around the world to talk about Agile.

00:01:51 Barbara Roberts: So, apart from an awful lot of experience of doing agile in the complex world, I’m actually, I’m unusually I’m a fully trained estimator as well. So many years ago, I was trained as an estimator for the purposes of putting together commercial bids, so it it’s quite an unusual combination of skills I think not many people can say they’re trained as estimators.

00:02:14 Barbara Roberts: So, what I want to talk about today is when you’re estimating, how do you do the estimation, how does it work in an agile environment? What’s different about estimating in an agile environment to a traditional environment and talking a little bit about the one thing estimators have to deal with is people want accurate estimates and there’s stuff you don’t know and how do you balance the uncertainty and and risk? How do you make the two works together and then I wanted to talk about how you choose the right estimating style. So, whether that’s who, why, when, how across a project life cycle.

00:02:55 Barbara Roberts: So first of all, why do we estimate? normally you do it for two reasons. Either you want to work out what it’s going to cost to deliver something specific, or sometimes we do it the other way round, which is I’ve got this budget. What can I get for my budget? Either of them are absolutely fine, there are times when you don’t need to estimate at work. If somebody says you’ve got free time, there’s no constraints. Just get on with this work and I’m not worried about the cost or the time frames. Then actually, sometimes you don’t need to create an estimate, but in the normal commercial words, well, somebody wants to know either what they’re going to get or what it’s going to cost. You get a result, so those are typically the two reasons.

00:03:39 Barbara Roberts: So first of all, when we estimate you want to understand what. So, what am I going to get for my money or what is it we’re trying to do. So, using this, the user story format as Barbara, I need transport to the office that I can facilitate a workshop. So that’s the first question, I as the user want to know what’s the estimate for doing that?

00:04:02 Barbara Roberts: So, the first question somebody’s going to say to me is how good does it need to be? And obviously, if you ask me, I’d rather have a Porsche. But if I’m on a limited budget, it might be that I hire a moped and it depends how good the solution needs to be. Then I need to understand, how much is this going to cost? So well, yes, you can have a Porsche. It’ll cost you X £1000 a day, a lot of insurance and it will cost you a lot to drive into London. Alternatively, you know if you are a scooter that’s gonna be much cheaper. And then finally, typically people want to know when they’re going to get this solution.

00:04:42 Barbara Roberts: So, these are the things that you’re juggling with when you’re asked to create an estimate. What am I going to get? How good’s it got to be? How much have I got to spend and when is it needed for? So as an estimator, these are often the the questions you have to ask. And the reason we create estimates is we need to support things like the commercial understanding and the business case. We need to do forward planning and we need to do some decision making. So quite often my estimate will result in somebody saying you must be joking. I can’t afford that or that looks a bargain I’ll have two or working out if that’s what it’s going to cost, if that’s how long it’s going to take when am I going to get it. So basically, the estimating is a support mechanism. It’s not the end goal in itself, it’s to support other things happening.

00:05:34 Barbara Roberts: And what we need to do when we’re estimating is make sure that we provide the right level of detail and no more for use in each circumstance. So not everything, not low-level detail, we can’t produce detailed precise estimates in the early stages of something if we don’t know much about it. And I often use analogies. So, when we were looking to do an extension at home. We were saying, well, roughly how much have we got to spend and based on that roughly very roughly, what could we get for our money.

00:06:04 Barbara Roberts: But it was only later that we had to go into more detail. So, it’s the right level of detail and no more for each circumstance. So, if we’re estimating for agile, then we need to take a slightly different approach, because if you work in a traditional waterfall type environment, basically you fix time you fix features. You say you’re fixing time; you say you’re fixing cost and often one of them has to give. And if you don’t fix the ones on the outside then quality is compromised. But typically, on a traditional project waterfall project is usually time that slips. What we do in agile is we turn things upside down. And fairly early on in a project we fix time, we fix cost, we fix quality.

00:06:52 Barbara Roberts: And what we allow to vary is features, so you won’t get everything in an agile project if we hit problems, the first thing we do is we drop the least most important feature so that we can still deliver on time. So that’s our working premise. So, in order for that to work, we need to create different plans at different stages. And what I do is we talk about horizon, and I’ll explain these in a bit more detail later, but I use analogies, examples to make you think what does the horizon look like. So basically, the horizons you work to are a telescope view. The big picture stuff, the binoculars’ view coming closer to you, a magnifying glass.

00:07:37 Barbara Roberts: Quite close and a microscope very detailed, those are the four sort of levels of estimating that you have to create in an agile project. So typically, you would use a different style of estimating depending on which of those views, which of those horizons you’re working to. And basically, the way we work in agile is that you’re building a solution based around iterative development and incremental testing, and what that means is you get frequent validation of your estimate in these short feedback loops. So, on a traditional project, you estimate at the beginning and quite often you’re not there at the end.

00:08:15 Barbara Roberts: And you never learn how good or bad your estimating is on an agile project you learn all the time. So, if you’re were estimating for a Sprint at the end of that Sprint, two to four weeks, you’ll know how good your estimates were, or what did you miss. You’ll know if you’re a pessimistic or an optimistic estimator, so you’ve got this feedback process into the estimating an agile that actually makes people become better and more confident estimators. Based on what they’ve done, what they’ve learned and how they can make it better next time.

00:08:48 Barbara Roberts: So, one of the important things working as an estimator is to understand some basic rules and as far as I’m concerned, there is one rule that you need to accept, and once you’ve got this one in your head, life gets a lot easier and it’s a very, very simple rule. And the rule is that basically an estimate is always wrong or almost always wrong, and this is perfectly normal and it’s to be expected.

00:09:15 Barbara Roberts: When I’m coaching teams, if my team constantly delivering exactly on their estimates every time. Then my perception is they’re overestimating to be comfortable. Whereas in reality it is highly unlikely that your estimates will be spot on every time, they’re nearly always wrong because life isn’t quite how you expect it to be. There are things that will happen that will affect your estimates, some of them you could have controlled. Some of them are outside your control, so once you learn or you accept that an estimate is almost always wrong then life gets a bit easier.

00:09:50 Barbara Roberts: So, there’s a misconception sometimes coming from above that I want 100% accurate estimate and people think if you spend enough time on that estimate, it will be 100% accurate. This really, really is a misconception that you simply can’t deliver a perfect estimate. You simply can’t, the reality is that even an estimate for the next 10 minutes can be wrong. How many of you have been working on something you’re trying to get finished and it’s a far drill?

00:10:19 Barbara Roberts: Or your boss calls you and says, could you just do this? The unexpected, the unplanned is always a possibility there’s technical term for this, it’s called “stuff happens” and stuff happens all the time. That’s the polite version and there’s always going to be uncertainty until you’ve done so at 5 minutes to midnight on the perfect project you can have a power outage, and everything goes pear shape.

00:10:45 Barbara Roberts: So, accept that there is uncertainty that always will be, and you cannot be perfect and it’s not something you should try and achieve. So, it’s the right level for the right point in time and if you’re pushed to give percent perfection, you have to explain that that just can’t be 100% accurate. So, what we need to do is understand that fairly early on, why are we trying to do this estimate? Because the purpose for the estimate will drive how long we spend on it.

00:11:14 Barbara Roberts: So, we need to do just enough to meet the purpose at this time, not loads and loads of effort to produce a very detailed estimate for a no-go decision early on in a project, we need to know some rough sizing, as if we spend about that much and we get about that much value. Does that sort of makes sense if people go? Looks OK so far, good if they say you must be joking, then it might be we kill the project there, which is good commercial decision making.

00:11:44 Barbara Roberts: So, early on in the project what we need to do is not waste time chasing details that doesn’t exist yet. So, on a traditional project, we’re used to trying to pin all the detail down in an agile project, we don’t want to do that. So, in the early stages of an agile project, first thing we need to understand is what are the key cost and benefit cost and business drivers for this project? Do we understand what they are? So, what are the business initiatives? What are the business reasoning behind it?

00:12:13 Barbara Roberts: Are there any constraints of cost? Is it as much money as you want, which is unlikely? Are there time constraints or is there a budget that we’re working too? because that will affect the way we do the estimating. And secondly, early on, it’s not helpful to take ages to provide this very, very detailed estimate. It might look precise, but in reality, it will prove to be inaccurate even though you’ve spent three months trying to produce the perfect estimate, you’d have been better spending a couple of a week maybe on it and then to get on with the work. So often in a project it’s much more valuable to produce a rough estimate very early on.

00:12:55 Barbara Roberts: So, what we’ve also found people have done studies on estimating and they’ve found that the time spent in estimating very soon reaches the point where the extra effort you’re putting in doesn’t prove any particular improvement in accuracy. It’s as good as it’s going to get fairly early on in the project when you don’t know a lot about the details and that’s absolutely fine and that’s perfectly normal.

00:13:21 Barbara Roberts: So, what we can see is that when you’re working in a project concept, you’ve got these four horizons, you’ve got the telescope, you’ve got the binoculars, you’ve got the magnifying glass, you’ve got the microscope and basically the estimating, and the planning is based around these horizons, these time frames, and depending on the horizon the time frame. It will depend the style of estimating the style of planning you use. So, we do not want detailed estimates and detailed plans right early on in a project because this stuff we don’t know.

00:13:55 Barbara Roberts: And we’re not going to know it at this stage, it’s going to come out later. So, the low-level detail of some of the functionality, we don’t know it yet, but we know enough to say that functionality is about medium size or that’s actually a small piece of work or that’s a horrendous piece of work we might need to think carefully about that one. So, there’s this intrinsic link between uncertainty and horizon.

00:14:19 Barbara Roberts: So, what we know is when you’re working to a big distant horizon, there’s a lot more uncertainty. So, let’s say I’ve decided to sail from Dover to the Bahama be nice, quite like that idea. If I was trying to plan that in detail, there’s no point. So, I can work out waypoints, but I can’t tell you that in 2 ½ weeks’ time at half of 3 in the afternoon I’ll be at this point in the Atlantic or the Pacific, whichever way I’m sailing.

00:14:50 Barbara Roberts: So, when we’re working to big horizons, the confidence will naturally be lower and therefore the accuracy will be lower. So, for example, if you ask me to create my predictions for 2024, they will be very much best guesses and I think a lot of us learnt that over COVID. I was due to spend the first six months of 2022, I was booked in to travel all over the world talking agile. I got as far as Chicago COVID hit, I got home before they closed all the airports down and from that point on, I didn’t do the travelling. I did the work I needed to do, but I did from home. So, we’ve learned that it’s very, very difficult to confidently predict the future because COVID proved that the almost decisions were made day-to-day because you were being hit with things you weren’t expecting and that’s perfectly normal. But if you’re working to a smaller horizon, if you’re working on something that’s nearer to you.

00:15:49 Barbara Roberts: We know more about that and therefore we we make less assumptions. So, my confidence will be higher. My estimates will be more accurate if you ask me what I think I can get done in the next two weeks, right. So, the next two weeks I’m out on Wednesday, so that will give me nine working days. If I based on the assumption that I do about 6 hour working hours in a 7-hour day, I can get about 9 x 6 about 54 working hours’ worth of working and I can plan that in more detail if I’m looking for a horizon that’s three months, six months, a year, I can’t.

00:16:26 Barbara Roberts: And won’t plan to that level of detail because there’s much more uncertainty, so accepting that it depending on where you are depends on the style, depends on the uncertainty, depends on the planning style, they’re all very closely linked together. So, make sure that the style of estimating matches the level of uncertainty. Don’t try and mismatch precise estimating with a loss of uncertainty cause it’s a waste of time and you can’t pin the detail down up front in an agile project because that’s not what we do. We accept that life is volatile, so we try to defer decisions until the last possible safe moment, that’s exactly why.

00:17:09 Barbara Roberts: So, I said before, we’ve got these four horizons for agile. We’ve got the long-term horizon, the big picture. So, if we’re looking at the big picture, we’re looking at life through a telescope, we’ve got limited knowledge, limited detail. Our confidence is low if I’m going to drive from here to Scotland, basically I need some high-level maps. I don’t want the very, very low-level street map of Edinburgh at the moment. I might leave it later, but I don’t need it at the moment.

00:17:41 Barbara Roberts: So that would relate to, for example, a whole project, the full delivery of a piece of work. There’s a lot more uncertainty. It’s a big picture, it’s a bit blurred around the edges, but I’ve got a rough idea of what I need to do. If we look at the next one, the medium-term horizon, so this is our binoculars, we’ve got better knowledge because it’s a subset of the big picture. So, I can focus in on this first subset that I’m going to work on and that might be the current or the next increment or release or the next intermediate delivery. So, I can now afford to sort of change my magnification and focus in closer on a smaller part of the map now. So, I’ll explore that and make it bigger and get more detail on this next one this medium horizon, so it’s binocular level.

00:18:31 Barbara Roberts: Going to the next horizon again, the short-term horizon, we’ve got good knowledge, we’ve got good confidence. So, this would relate to things like estimating and planning for the Sprint we’re about work on so. If we assume that best guidance for sprints will be two to four weeks, we as a team can plan what we’re going to do for the next two to four weeks based on we’ve worked out who’s got holidays, how much time people have got available, everybody’s looking fit and healthy at the moment. That could change obviously, but at the moment it looks like we’ve got a full team for the full 2 weeks, this is the amount of work we think we can fit in.

00:19:06 Barbara Roberts: So quite a lot of confidence, still a little bit of unknown and I’m afraid, apparently, is sneezing yesterday. We’re hoping it’s high fever, but if he’s coming down with a cold, we could be in trouble here. So that’s the short-term horizon. More confidence, more knowledge, better estimates, more precise estimates. And then the final horizon it’s the immediate horizon, so that’s the very detailed knowledge where we’re highly confident and that would be, for example, at the daily Scrum, the daily stand up when I’m telling you what I’m planning to do in the next 24 hours.

00:19:40 Barbara Roberts: And based on I know I feel well, I’m expecting not to be interrupted. In fact, I’m working from home and I’m going to switch the phone off, so I know that I’m going to be able to give my full attention to my work. So, unless we have an alarm goes off in the house, I can dedicate my time. So different horizons, different levels of confidence, different styles of estimating but also accepting even in all those four, that stuff can happen to any of them.

00:20:07 Barbara Roberts: You can be working in the office there’s a fire drill. You’ve done your daily scrum, what you’re going to do today, and you basically have to file out, stand in the rain for 20 minutes and then walk up 7 flights of stairs and there’s an hour gone. You know, stuff happens and it’s not somebody’s fault it’s just life.

00:20:25 Barbara Roberts: So that’s balancing the horizons of confidence and the uncertainty. But what we also have to deal with is the unknown, and this is where people get very uncomfortable because they feel they should know. And if they don’t know, why don’t they know? And management sometimes says, well, you should know. You know, I want a precise estimate and sometimes you need to have the confidence to say, you know what, I’m not sure.

00:20:51 Barbara Roberts: But I’ve got a way of dealing with it and the way we deal with the unknown is as an estimator, you make an assumption. And we will do this anyway but what you do as an estimator is you make this very, very visible. So based on the assumption that everybody is committing to this fully and they’re doing a normal day’s work. This is what we think we’re going to get done, so assumptions are absolutely invaluable for the estimator we make them in our head, but in our estimates, we actually need to make them written down. So, for example, I did a big estimate for a big piece of work for a large customer and one of the assumptions that nobody wrote down was that we would have a test environment in place on day one.

00:21:38 Barbara Roberts: I said, well, OK, that’s fine. But it’s not there now, so you need to write that down. So, we wrote down against our estimate based on the assumption that the test environment will be in place on day one, this is what we think we can do. Interestingly, it wasn’t delivered for about two months, and when people said, well, it’s your fault, your estimate was rubbish, we could say no, I’m sorry. You know, you saw the estimate, you said that would be delivered. It wasn’t delivered, it was an absolute blocker for us and that’s why we have problems.

00:22:07 Barbara Roberts: So, what we need to do is use assumptions to make informed guesses about any factors that might influence our estimate. So, we’re estimating for time and money what are the things that realistically might hit that that could cause us problems. So, for example, I’m doing an estimate in the early stages. Assuming that I’ve got a team that have worked on this particular software before, are skilled at it and aren’t going through a steep learning curve. If you give me a team of people who’ve just joined the company this week and haven’t done their training yet, then my estimate is going to be wrong. So, I make these assumptions and they will affect the time or the money that I’m estimating.

00:22:50 Barbara Roberts: And basically, I write them down very, very clearly assumption one assumption, two assumption, three and then very importantly, I need to make sure that they are absolutely linked together, and they can’t be separated. So, you can’t have the estimate without the assumptions, because if you can’t see the assumptions, you’ve no idea whether it’s based on quicksand or concrete. And in my experience, when an estimate is wrong, it is nearly always because one of the estimates, one of the assumptions was wrong or misguided or needed revisiting.

00:23:26 Barbara Roberts: And in the early stages, if you’re finding problems, go back to your assumptions, challenge your assumptions. So, we talk about challenging estimates and I’m sure you’ll all been in the situation. You’re doing an estimate, and somebody says, well, I don’t like your figures. Could you give me a smaller number and the answer to that is yes, of course. What would you like to drop? But that’s quite difficult when it’s a senior manager. But what we say to people is you can’t say that’s too much time or that’s too much money. What you can do is say can you explain to me assumption one, you’ve said assuming we have a team whose skill to do this?

00:24:03 Barbara Roberts: How confident are you that we’re gonna get the right people? Because if we if that’s unlikely, then we’re gonna have to up the estimate. So, we’re more likely to talk about these assumptions than the physical numbers that we’re talking about. So, the assumptions and the estimate must be literally chained or stapled together so they don’t get separated. And what you find is the assumptions are very closely associated with risks. So, if you’ve got a big assumption then that equates to a big risk.

00:24:38 Barbara Roberts: So basically, any estimate that’s got a very, very big assumption on it. You may want to explore that assumption to find out whether it’s true or false, because if you’re the assumption proves false and it’s a big risk, then that could be a stopper for your project. So, an invalid assumption can significantly affect an estimate. Can significantly affect whether a piece of work should go forward or not.

00:25:04 Barbara Roberts: For example, we often do analogy estimating, so we’ve got a new piece of software and I’ve been told that this is very similar to a piece of software that we’re already familiar with. So, I would make that assumption based on X is similar to Y and we know Y it’s about this big. But what we then typically do is we take the new software, and we do some sort of proof of concept to check whether my assumption is right or not. And that is a normal part of estimating to sort of validate the assumptions.

00:25:38 Barbara Roberts: So, validate the major assumptions as soon as it’s practical and apart from anything else, this is good practise for dealing with risk. If you’ve got a big risk, you don’t put your fingers in your ears, shut your eyes and you know hope that it’s gonna work out. If you’ve got a big risk or a big assumption, look at it sooner. Check it out, don’t just say well, accept that and see what happens later and this also aligns very, very clearly with Agile fail fast approach.

00:26:06 Barbara Roberts: And pick when I’m talking to people about agile, they often pick this up and say no, you’re agile, you just want to fail. No, I don’t want to fail all I’m saying is, if you’re gonna fail, fail as early as you can so that it’s cheaper, quicker to fix it or you haven’t thrown away a lot of money. So, if you’re going to fail, find out as early as possible. When you’ve got more decisions, if you fail at 5 minutes to midnight, there is very, very little you can do to fix things because it’s almost too late and you’ve got no choices.

00:26:37 Barbara Roberts: So, an example you might identify a risk and to address that risk you might say, right, we’re going to do a proof of concept or some sort of architectural spike that might be critical as part of your feasibility your foundations to support a goal. No good decision on this whole piece of work. So, spend a little to either save a fortune or feel a bit more comfortable to move forward.

00:27:00 Barbara Roberts: And just a top tip from me as a as an estimator doing big complex commercial estimates, I always present my assumptions before I give anybody the figures. So basically, people understand that they these are the assumptions based on these assumptions. These are the figures, so it highlights that the assumptions are the foundations for the estimate, not an afterthought and that’s really, really important.

00:27:30 Barbara Roberts: So, sometimes people have a habit of taking the bits out of an estimate they like. You quote a range, and they quote you the left of the lowest end of the range instead of the whole range. So, make sure they stay closely linked to the assumptions and the estimates. So, I give you a very, very simple everyday example, so I’m chatting to somebody at work, and I’ve told them I’ve got to be in Manchester tomorrow and I reckon I can do it in about 4 hours.

00:28:00 Barbara Roberts: And if I say, OK, you know, it’s gonna take me about for us to drive to Manchester, I’ll get one of three answers. It will be OK thanks for that or that seems a long time. Well, that seems quite quick because I’ve given very little information. So, I got very simple questions answers back. If we state the assumptions against this which were actually in my head, but I didn’t make them explicit.

00:28:25 Barbara Roberts: So, I can drive from London to Manchester in about four hours, assuming I can use the motorway, there are no major holdups. I avoid the rush hour and I keep to the speed limit. They’re sort of in my head, but now I’m making them visible that gives me a more intelligent conversation, because people will then come back and say, OK, so. You’re looking to, you’re gonna avoid the rush hour. Can you avoid the rush hour if you need to arrive between 5:00 and 6:00? And what about those long running roadworks on the M6? Will they be finished by then? So, my assumptions lead to better conversations. That’s why they need to be visible and that’s why they need to discuss. Because it could be that somebody knows the long running roadworks are running on longer than expected and I didn’t know that.

00:29:13 Barbara Roberts: So, it’s perfectly normal and valid to talk about the assumptions and if necessarily amend them. That’s all part of estimating, it’s not a question of your competence. So, the other thing we have to think about is when we do an estimate, we need to present the estimate in a way that reflects my confidence in the figures because sometimes it’s finger in the air, best guess on smoke, mirrors and a little bit of vaguely previous experience.

00:29:45 Barbara Roberts: Certainly, any early estimates will have uncertainty and I need people to understand right from the start that if it’s an early estimate, there are a lot of unknowns and therefore my confidence in this is probably not even medium, it’s probably low. Or, you know, even tinging on the red I might need to do an investigation before I can even give you some figures.

00:30:08 Barbara Roberts: The estimate that that we create as estimators is to support decisions by the business, and this is often misunderstood. There is often a lot of pressure put on the estimator to create estimates that look nice, that the sort of figures that the business wants to receive, what we estimate should be realistic based on our level of uncertainty. And the risks either probably the probability and the impact of the risks too, that we’ve highlighted in the assumptions.

00:30:39 Barbara Roberts: What you can’t do as an estimator is own those risks. So, I always talk about on a project the risks to the project sit with the business, so I can’t decide how risky the business wants to be. It’s not my role, I’m not senior enough. I’m not, I don’t have enough clout to make those decisions. So, I worked for a company when I was doing commercial estimating and we did a risk assessment. And I could decide whether a piece of work could go ahead to a certain level of risk, and this was done on risks and probability and impact grids, so I could decide up to about level twenty. Twenty to thirty had to go to my boss, and anything above thirty had to go to the CEO.

00:31:24 Barbara Roberts: Because it was a big risk and there was a risk to the company and the lower management team couldn’t take on that responsibility, so the risks on an estimate do not belong to the estimator. They belong to the person that asks for the risk. We give them the information; they make the decisions so need to think about what is driving this. So, the business will think right, this is a loss leader. Yes, it’s risky, but we need to get a small foothold in the market, or we need to get out there to deal with the competitor threat or it might be well, this is very risky. Do we really need this business? As an estimator I can’t decide that.

00:32:03 Barbara Roberts: You may wonder, what elephants have got to do with estimating? So, when I was working with Nokia, as happy times spent out Finland, freezing cold and Cambridge and places like that. And once lunch time I was talking to the lady that does this or did the strategic estimating for Nokia for the next three years. So, she created a three-year plan and I just said to her over lunch she do. So, I’m curious, you know, you’re doing this big, big planning. How do you do it? and she said well, I’ll tell you this, but don’t tell anyone. So, you didn’t hear it from me actually, she’s not in Nokia anymore, so it doesn’t matter, she said. I think about them like elephants, she said, and I think about herds of elephants and all I’m trying to do is very, very rough, roughly put them in a line where I’ve got some big ones. I’ve got some small ones, some of them are very big and but very risky. They need to come to the front of the queue, some of them are big, but they’re we don’t need to address them yet, so I put them to the back of the queue, she said. All I’m doing is very, very roughly sizing, saying that one looks about a year. Ohh that one, I don’t even know we’d have to investigate, that’s quite small, that’s about three months.

00:33:14 Barbara Roberts: She said because when they get picked up, those estimates will get looked into in more detail. Mine is just the starting point. It’s nobody’s gonna come back to me and say, well, you said it’s three years and it took longer than that because she said it’s irrelevant by then all you want is a rough queue of elephants. I’m giving you a rough queue of elephants of various sizes and to me, that’s a very, very good analogy. Because what you need to do at that stage is do very rough estimating and it’s so vague it will get picked up later. It’s not supposed to be accurate, you know, it’s just enough so that we can create something that we’ve got a rough idea of what the future might look like knowing it will change, hence the estimates. So, sometimes in the early stages, I’m mentally thinking Elephants.

00:34:04 Barbara Roberts: So first of all, if we estimate for the long-term horizon, the big picture, the full delivery, what we have here, if you look at it, it’s a photograph of a view. There’s stuff in the distance, vague and hazy. I can’t see the top of it and that’s actually the Cheviot. I believe you know I can see detail in the foreground, I can’t see the detail further out. My knowledge is limited, and my detail is very limited and that will affect my estimates. So, there’s a lot of uncertainty here and flagging a red significant uncertainty.

00:34:37 Barbara Roberts: So, there’s going to be a lot of assumptions. I can’t be precise, even though people often demand accurate estimates, I can smile sweetly and say I’m sorry I can’t do that. It is not possible, yeah, I cannot give you that sort of estimate. So, my level of confidence is low because of the uncertainty. Therefore, I can only give you a very rough, reasonable idea of what’s needed enough for big picture planning so we can plan the route towards future position, that’s all.

00:35:07 Barbara Roberts: And just to give you a very unreasonable example, in my experience, when I was a manager at British Rail and we were the Agile team and we were working for commercial customers, this guy came into me and said, Barbara I need an estimate. So basically, what I need is and he outlined five statements. And he said what I’d like from you is a fixed price estimate to include five-year support and maintenance.

00:35:33 Barbara Roberts: And he just stepped back, and he was just going to leave. And I said, that’s fine, I said I can give it to you now, if you like. It’s oh, that was quick so, what’s it looking like? I said, well, I think it’s probably gonna be about £10 million. And I said, but that seems an awful lot. I said that’s because you don’t know what you want, I don’t know what you want. You’re putting all risk on me, looking at what you’ve roughly described. It’s probably about £1,000,000, but I’m putting in 900% for the risk on me. Alternatively, let’s talk about it a bit more. And I’m not going to talk about a fixed price for support until we’ve got some idea of what we’re actually delivering, and we got the work. So, people need to understand that we cannot give that accurate estimate that full on commitment to accurate detail when we simply don’t know and it’s just a fact of life. So that’s the long-term horizon.

00:36:26 Barbara Roberts: The next one, the medium-term horizon, is your incremental release planning. So, I’m now focusing on an element of this piece of work. So, I’m now going to focus on the new customers’ bit of this, this new piece of work that we’re developing. So, the view is now clearer because I can take all the other stuff away and focus on new customers only, that’s great, so it makes more sense. So, I’ve got better knowledge of this. Because basically we’ve got more details available. So yes, I’m still making assumptions, but they’re not so critical because the time frame is smaller. So, there’s still uncertainty but I know more about what I’m trying to do now because I’ve pinned it down to a the next level of detail. So, my confidence is improving compared to the long-term horizon.

00:37:14 Barbara Roberts: You’re going to get better figures from me, enough to plan the increment, the release, and what will fit in that roughly. So, I’ve got enough now to plan the delivery of the increment. In other words, how long? How many sprints? Roughly possibly what the Sprint objects are going to be. But I still don’t have the low-level detail perfectly normal for agile. We don’t want to know yet the low-level detail for agile. We want the low-level detail about 5 minutes before you need it. Because that’s the last point when you can pin it down and it’s gonna be as accurate as it can possibly be so, that’s the medium-term, Short-term horizon. So, this is a very clear view of what’s close to us and it is all becoming clear, so this is for example planning for a Sprint. I’ve got a good knowledge now of what the low-level detail is. We’ve got detailed stories requirements that we’re going to take on. We know what tasks we’re going to need to do to deliver those stories, those requirements. So, any assumptions here are minor.

00:38:18 Barbara Roberts: Based on the assumption that the network doesn’t keep going down this week like it did last week, we know what we have to do. We know how we’re going to do it so pretty good estimating. Therefore, we’ve got high confidence because we know what we’re gonna do and how we’re going to do it. And who’s gonna do it potentially. So, we’ve got enough knowledge now to plan the next two to four weeks with a reasonable level of confidence.

00:38:46 Barbara Roberts: There’s still a little bit of uncertainty, but there’s less compared to the release compared to the big project picture. And then the immediate horizon, the next 24 hours, this is what we’re planning at the daily scrum, the daily stand up. So, we’ve now got a very, very clear idea of what’s in front of us directly. So, we are talking about what me personally, what I’m going to do in the next 24 hours based on I know I’m feeling good been on my desk is clear, I’ve got no other interruptions. Nobody needs me today; I know what I can do. I know what I’m capable of, I know exactly what I intend to do. So that’s what I’m committing to. So, my confidence level is very high.

00:39:28 Barbara Roberts: The only thing I need to think about is the unexpected, so I can plan what I’m going to do today, but I can’t predict fire drills, I can’t predict the boss asking me. Could I just do something for him? Could I fix something? I can’t predict the stuff happens, so it’s still possible even in a 24-hour horizon, but it’s a lot more accurate than my project view. So, what we can do is we look at the project lifecycle and we can link confidence and uncertainty across the project contacts. So, if we look at a project in terms of four stages, we’ve got the rough ideas, the very early thinking we’ve got the work on the planning for iterative developments. So, what are my building blocks? What are the basics I’m working to?

00:40:18 Barbara Roberts: We’ve got the iterative development, so we’ve got the building blocks where we’re actually creating elements of the solution and we’ve got the deployment part of it where we’re releasing elements of the solution, whether we’re releasing them as a series of incremental releases or whether we’re doing a Big Bang release at the end. It doesn’t actually matter at this stage. So, if we look at that as a basic project, what we can say is that in the early stages, our level of confidence level of unknowns will decrease in the very early stages. There’s a lot we don’t know once we get towards deployment, we know just about everything, the uncertainty is much, much lower. By comparison, working in parallel, our confidence, our estimate accuracy increases across the life cycle.

00:41:08 Barbara Roberts: So as one goes down, the other goes up and they’re very closely related. So, if we’re doing an estimate in the very early stages, lots of unknown. Therefore, we cannot be accurate if we’re planning, we know more, but we still have quite a lot of uncertainty if we’re planning to do a release and its sort of the day before the release is going live. Then we know an awful lot, and the uncertainty is much smaller. So that helps put the whole thing into context. So, if we put on there, we have the in the telescope. We’ve got the binoculars, we’ve got the Sprint, the magnifying glass in there and we’ve got the daily scrum the, the microscope. That is exactly how those horizons fit across a project concept context.

00:41:57 Barbara Roberts: And in the same way, the style of estimating we use across the life cycle depends on what we’re trying to do. So, we talked about understand what you’re trying to do. So, in the very early stages, the very early thinking, all we’re trying to do at that stage is support early decision making. So, for example, coming up to a, we know a little bit about this. We’ve got a rough idea of cost, a rough idea of time. Is it a go or a no go? Should we spend more money on this, or should we quietly bury it now?

00:42:28 Barbara Roberts: So, what we do there and what we can only do there is some sort of top-down estimating typically by analogy, if we’re going to do an extension, we know roughly that to build X number of square feet. It will cut for a single story, building it costs about that much. So, if we’re gonna build, I don’t know 100 square feet then it’s going to cost us about that much very roughly. It doesn’t take into account the gold-plated Goosey bath or stone Masons sort of stone walling. It’s a basic model, but it’s enough to say, can we afford to do something or not?

00:43:05 Barbara Roberts: When we move on to the next stage, which in Agile PM terms will be feasibility and would be foundations, we want to create plans now. So, what we’re trying to do is create some more sensible high-level plans. What would the overarching view of the project look like and potentially how many releases do we think we might split it up into again here because there’s a lot of uncertainty still, we can do top-down estimating. So, we group things by similarity, or we use analogy. Well, that looks roughly like one of those. So here we can use groupings, whether they’re T-shirts or story points. Work nicely here but we can’t do bottom up estimating when we break it down and work out that that’s 5 minutes, that’s 10 minutes, that’s 15 minutes and you add it up. That doesn’t work, it takes too long, you don’t have the details, so it has to be topped down here.

00:44:01 Barbara Roberts: When we move into iterative development, we’re trying to do here 2 levels of things. So first of all, what we’re trying to do all the time is we’re going to prepare for what’s coming next. So first of all, if we’re working in increment one, we are trying to also rough size increment two. And if we’re working on Sprint one, we’re trying to rough size Sprint two. So, when you’re doing planning ahead, we do top-down story point estimating to prepare for the Sprint planning session to make sure we’ve got enough stories or requirements ready when we go into Sprint planning, and we also do top-down estimating.

00:44:47 Barbara Roberts: Typically, story points to roughly sized things when we’re working out what might go into the next increment. So that’s are they preparing for the next steps but what we also need to do in this iterative development cycle is do the task planning for the next Sprint and for deployment. So, when we’re doing the task planning for the Sprint, what we want to do is do it as accurately as possible, and for that reason we would normally do bottom up estimating here because story points are not detailed enough. They’re not accurate enough, and if you burn down story points, you’ll burn down as flat line, drop flat line drop. We know what we’re going to do, we know the tasks we’re going to do, we know how long it’s going to take. So, if I’m a developer, I say right for this, for this story, I’ve got to create a screen, create some test data, create a table.

00:45:37 Barbara Roberts: We’re going to have to do the coding, I’m going to have to do the testing, you know, five hours, two hours, 3 hours, 7 hours, one hour, whatever. And I can add those up and I can do that accurately because it’s small and it’s close to me. Similarly, here when you’re planning for deployment, you plan for the tasks you need to do right. To deploy this, I’m going to have to run the whole test suite again, flag up that there’s no critical errors to the performance testing I’ve got to go and have a review with the deployment manager to reassure him or her. But this is safe to go live, and then we can just hand it over. So, because it’s small because it’s close, because there’s less uncertainty we can do. That’s how we do it.

00:46:23 Barbara Roberts: And finally, just to think about things to consider when you’re estimating and I love this, this was some information from Donald Rumsfeld, who was the former US Secretary of State. And basically, what he said, “There are known knowns”. In other words, there are always things that we know, we know. So, the example here is if we know the height of the building and if we know how far we are, we are away from the building, we can, you know, we can do the calculations and work out certain information.

00:46:57 Barbara Roberts: So, if you can measure sort of at 3 feet, then you can work out exactly how high the building is. There is mass, there is stuff in place that we can do that. So, if we’ve got known knowns, we can estimate easy, life is good, life is simple. We can give you a good estimate for that based on what we know. So, if I’m. estimating what I’m going to do to do a particular piece, that is my job as a developer. It’s a known known, I know what needs to be done so I can give you estimates.

00:47:28 Barbara Roberts: But there are also going to be what we talk about as known unknowns. That’s to say, we know there are some things we don’t know that is always going to be the case. So, what do we do about them? We can make an assumption. We might want to do an investigation, but we need to do something to do with the unknowns. So, if it’s something we know we don’t know, let’s go and find out. So typically, what we need to do with those is we need to investigate. And then estimate and then finally there are what we talk about as unknown unknowns. What I love is sometimes people estimate and they do risks, and they do a risk assessment based on what we talk about of black Swans. You can’t estimate for things that you have absolutely no idea what they are. There are things you can do ideally what I would do here is I would do a sort of a risk-based estimating.

00:48:24 Barbara Roberts: And I’ve got examples of how that can be done. You look at your major risks, you work out if that hit. How much would it hurt us and what is the probability of that hitting? And you do some math, and you say, right? If that is, if that could hit 10% of my costs, then I’ll add on 10% into my estimate for that specific risk and you make it very, very visible because you can’t estimate things you don’t know. So, another example would be if you are doing as a supplier. If you’re doing a commercial estimate for a customer and you don’t know the customer and there’s a lot of uncertainty. As we all know from the supplier side, you’re building contingency for your risk, which is why I quoted 10 million rather than one.

00:49:12 Barbara Roberts: Because there was a lot of risk for me and none on my customer. So, that is perfectly normal, so that’s my gallop through the basics of estimating and one of the things I did during COVID cause I had time to spare is I put together an e-learning for estimating and if anybody’s interested in taking it, it’s not expensive. It costs about the same as a book, I think and basically Knowledge Train are putting this up and you can book it through them if people are interested in the full details and it’s in seven sections and each section has got little quizzes, it’s got a sample paper and at the end there’s a multiple-choice paper. And if you succeed in the multiple choice, I think you get I think it’s 40%, I believe if you could succeed, you can print certificates. So, you know your stuff if you don’t succeed, you can have another go and it’ll generate another paper because for me, that gives you the opportunity to relearn or go over again or improve your score just to show to your friends that you got 100% if that’s important to you. So, that’s a lot of what I talked about here is based on what’s in the e-learning the estimating for agile course. So that’s me, how are we doing?

00:50:32 Barbara Roberts: Pretty much 50 minutes, not bad. So, if I said it would be about 45 to 50. So over to you guys’ questions.

00:50:39 Sevcan Yasa: Yeah. Thank you so much, Barbara, I hope everyone learned something there in terms of the course, I will be sending everyone an e-mail when it is up and going. So, if you in the meantime, if you do have any questions about the course, you can always e-mail us. You should have received an e-mail from me yesterday and today, but just in case I am going to write my e-mail down. Just before we head over to the Q&A and sort of give some time so people can think of questions. Just going to quickly pop up a survey, just to get your feedback.

00:51:27 Barbara Roberts: And I don’t see this. So, if you all want to say it was rubbish, that’s oh, I do see it. You better be nice to me then. It’s always difficult to know what people were expecting and how much they already know as well.

00:51:45 Sevcan Yasa: So just while people answer the question, well, the questionnaire, we have a question from Carl. I work in the NHS dealing with lots of projects that are subject to regulatory requirements. Would there be anything specific to consider with regards to estimation when dealing with a project subject to loss of regulation?

00:52:06 Barbara Roberts: Yeah. One of the interesting things about regulatory and the thing is there’s the perception that as soon as you say regulatory it is Rolls Royce, and everything has to be done. And again, with a regulatory project, you need to understand what is what would meet the regulations and what would vastly exceed them. Because in my experience so often people squeeze stuff into regulatory and say, well, you know, if we’re doing that, we’re going to do a Rolls Royce and actually sometimes all you need to do is enough to be good enough. So, for example, if I’m stuck in the rain, if somebody will offer me, you know, a Vauxhall car that will get me home, I don’t demand that you give me a Rolls Royce. I had a situation recently. Our car broke down and the company said I had to have the same car as the one that had broken down and they got a I think it was a Vauxhall outside and we sat waiting 4 hours for a car that was the same as mine, didn’t have one and eventually I said I’m taking the Vauxhall and that’s it. It’s understanding what is good enough for a regulatory project and if you’re involved in it, sometimes challenging, don’t accept it’s regulatory. We need everything we don’t, people often use it to squeeze in more stuff. So, what needs to be there as a bare minimum on the due date and what is negotiable, particularly if you’re trying to do agile.

00:53:26 Sevcan Yasa: Thank you, we do have some positive comments. Interesting, session very clear, interesting session, great answer by Carl. So, thank you.

00:53:40 Sevcan Yasa: Does anyone have any more questions?

00:53:41 Barbara Roberts: When somebody asked me something really difficult or shared something that you had a problem with.

00:53:48 Barbara Roberts: Interestingly, one of the deliberate targets of the e-learning course is not just the estimators, but the bosses and one of the companies I’ve been working with. They bought 200 and it was the senior managers that went through it as well as the teams. Because I was saying to them what you’re asking is unreasonable, you need to understand why you can’t ask that here, because your team’s going to tell you you’re not having it. Now you’ll understand why, and they said they also found it very useful. So, it’s not just for estimators, but for recipients of estimates.

00:54:34 Barbara Roberts: OK.

00:54:35 Sevcan Yasa: Yeah. Can you see the questions?

00:54:36 Barbara Roberts: We talk about agile estimators and methodology; how does this compare to other methods? Is agile the best? Obviously, I’m biassed agile is the best, but it’s not always the right answer. I’m talking about estimating fragile and a lot of the techniques that talk about in here would be equally applicable to a traditional project. So, in the early stages of a traditional project, when you’re still doing the early stages and the go, no go gates, the analogy, and the rough sizing it’s equally applicable. The horizons might be slightly different, but it the style is the same and yeah, I’m a great. I love agile to death but there are certain projects that I would not do agile because they’re not volatile enough. There’s no value to doing it agile. I’ll certainly get people to use some of the agile techniques to improve the communication and the collaboration, but I’m not one of these people that says. Agile or you’re not trying hard enough there is a place for traditional waterfall style projects.

00:55:35 Barbara Roberts: And I was talking to a customer this afternoon. They have a lot of mainframe legacy stuff and they’re working on it and it’s not super suitable for agile and that’s absolutely fine. So agile is good at what it’s good at, but it’s not the answer to every problem. But the techniques here are applicable to any sort of approach. We use them at home or building projects renovations, all sorts of things. How much we need to get done before we’re going on holiday, all sorts of things.

00:56:04 Barbara Roberts: How does I? I couldn’t read that, and it disappeared. It was, how does estimate close something and it disappeared.

00:56:13 Barbara Roberts: Is it possible to go back one Sev?

00:56:17 Sevcan Yasa: Do you remember the name?

00:56:18 Barbara Roberts: No, I’ll answer Joe’s then since it’s on there. What techniques would Barbara advise for merging upfront cost expectations of projects, owners and project sponsors unfamiliar with Agile? I think it’s partly explaining to them this this concept of certainty, uncertainty and how we can’t do accurate.

00:56:38 Barbara Roberts: So, in the early days it’s explaining I can’t give you an accurate estimate because to get the detail to give you a what looks like an accurate estimate would take longer than it would do to the work. So challenging, what do you need this estimate for at this point? If it’s just for a decision-making point, I will give you enough information so you can make the decision as whether we stop or we move on. So, I think a lot of it is educating the recipients of the estimates because they are very unreasonable and, in my experience, people come up and drop something on you and say could you just estimate that and your lunch break won’t take long?

00:57:14 Barbara Roberts: And then they want more in peace in microscopic detail, and it’s just not fair. And I found that when people understand more about estimates, they’ve got more confidence to push back and say that is not reasonable but what I can do is this. So, you don’t just refuse, but you give a helpful answer about what you could potentially do.

00:57:36 Barbara Roberts: Ohh right, Vicky.

00:57:39 Barbara Roberts: Sprint carry over, basically, there shouldn’t be such thing as automatic carry over. It should go back on the backlog to decide what to do about it. But also, if you’re getting a lot of carry over then the question to the team is let’s retrospect our estimating. So, it might be let’s pick on Vicky since I can see her name and she’s raised this. It might be Vicky is the most optimistic person ever and looks at things. And yeah, that’s be about that big or it might be that Vicky’s very pessimistic, and our estimates are too big with agile because you get the regular feedback. So, let’s say you’re in sprints every two to three weeks typically.

00:58:18 Barbara Roberts: At the end of 2-3 weeks, you will know personally how good your estimating is and you learn, so it’s not beating people up saying your estimating is rubbish. We always turn it into a bit of a friendly team coaching session. Come on Vicky and when we do the sprint planning next time, we’ll give you a Black Hat. Put this Black Hat on, try to think you know, sometimes it’s not quite so nice. Try to think less positively or sometimes coming up with checklists of have you thought about this? Have you thought about that? So, in my experience with agile, my teams get better and better and better because of the short feedback loops, and it makes a huge difference.

00:58:58 Barbara Roberts: So, I don’t know if that helps, but just be aware that there shouldn’t be an automatic Sprint carry over because if you do that, what you’re doing is you’re not reevaluating, you’re just pushing and pushing stuff further away and it will all hit you at the end anyway. Maybe it might be you’ve got enough now, and you need to drop something and pick something else up. So, it should go back onto the backlog to decide where it goes next.

00:59:23 Barbara Roberts: Vicky, still speaking to me, that’s alright. So, a question for you. Vicky, you have to think about are you an optimistic or pessimistic estimator? In my experience testers are very good estimators because they are the world’s most depressed people. They think about all the negative things that could happen and developers are often exceedingly optimistic because they’re very positive. But both sides, you know, need to come together, and understand how each other estimates.

00:59:53 Sevcan Yasa: Yep, thank you for that. Do we have another question? For the question is how much experience do you need to be an estimator?

01:00:03 Barbara Roberts: In real life, a bit, I think, but I mean I’m not a builder, but when we were doing the rough estimating for building here, I looked stuff up. I got some figures for, you know, cost per square footage or how do you estimate for a building? If it’s, if you’re estimating for, for example, for software and building for software, then ideally it needs to be people that understand how that works, because the worst thing is an estimate by a manager for a piece of work that they know nothing about. So, it might be the managers putting the estimate together, but normally he or she would work with somebody that understands the underneath the bonnet. If you like, Project managers often estimate very optimistically, because they’re not dealing with the day-to-day stuff that people in the team get hit by, so you don’t need to be.

01:01:01 Barbara Roberts: You don’t need to be very experienced, but you do need to know a bit of what you’re talking about just for your estimates to have Creedence. But if it’s something entirely new and nobody’s ever done it before, then it has to be a stab in the dark. But people often talk about sort of, you know, finger in the air, estimating that is actually normally based on some sort of relative experience, some sort of you don’t just say ohh. I think it’s gonna be about 5, you know five weeks. You’re mentally thinking in your head well, I did something vaguely similar, and it took about 3 weeks. This looks a bit more complicated, so I’ll add a bit more on so there is logic behind all of what we do.

01:01:44 Sevcan Yasa: Thank you. Another question, how does estimate class apply to the described process? Are all estimates to be considered equal i.e., same class or is class dependent on the horizon?

01:01:57 Barbara Roberts: I’m not quite sure what’s meant by estimate class. Do you mean the style of estimate?

01:02:02 Sevcan Yasa: To be honest, I’m not entirely sure either.

01:02:04 Barbara Roberts: That was the one I couldn’t read fast enough. So, whoever wrote that, if you could explain what you mean by estimate class.

01:02:12 Barbara Roberts: Because basically the way you estimate is driven by where you are in your life cycle and the amounts of knowledge compared to uncertainty and it’s that balance.

01:02:28 Sevcan Yasa: I don’t know if they are still with us.

01:02:29 Barbara Roberts: If they’re not, I’ll try and if there are any on there that I’ve missed, I will try and pick them up and answer them if I can. I might send them to Sev, and she can send them out to everybody as long as there’s not hundreds I haven’t seen.

01:02:48 Sevcan Yasa: Does anyone have any more questions?

01:02:50 Barbara Roberts: Somebody’s typing.

01:02:53 Barbara Roberts: Ohh James is typing so I’m hoping that James is the one that was going to explain, two people are typing now.

01:03:08 Barbara Roberts: At least people can’t see what you’re talking, OK? Ohh.

01:03:13 Barbara Roberts: Somebody enjoyed it, it’s good. It’s quite depressing that nobody’s taught to estimate. I actually went through estimating training and interestingly, I worked when the bids, the Ministry of Defence was taking bids for doing the fly by wire for the Eurofighter. I worked on the supplier side, and it was a consortium of three defence suppliers. Bidding to Ministry of Defence and the bid was an agile estimate. It was an agile bid based on Agile PM actually and we won the bid based on agile estimates and I was advising them on how to estimate and it went live. It was successful and as far as I’m aware they’ve had no problems with it. So, when people say agile can’t does can’t do big projects and estimates need to be accurate. And interestingly, this was a commercial bit, and it went well.

01:04:06 Barbara Roberts: OK, draught plans for sales I worked up a template. If the template works great because a template is good, it will tell you the things you need to be thinking about. So, if you’ve got the template and it’s good, great, but what I would do regularly is just look at it and say, hey, guys, could this be improved? I found this is a problem, we’ve had problems with certain estimates, maybe we need to add things to the template, so templates are great. Just don’t switch your brain off. Don’t just assume you do what the template tells you and don’t think. So, you can add it to a template as well. Let’s say you’re doing a particularly unusual sales project, so you might need to do that something slightly different. It might be a new customer and there might be a particular risk.

01:04:52 Barbara Roberts: So, use the template as a starting point, but by all means change it or amend it. We shouldn’t be driven by rules I think rules, things like templates are there to guide you. But they shouldn’t constrain you, so you know for me, things like Agile PM is a guide. It’s not a rule book, it helps you, it says here’s a good starting point. But if you need to do it slightly differently, then do it.

01:05:21 Barbara Roberts: So, you’re hoping that the inheriting PM perfects and makes the plan more accurate based on further research and development, perfect. So, state your assumptions when you had your estimate over. So, I’ve used the template. I’m assuming that you will be doing more R&D onto this so you can refine the plan. And then you all covering yourself but explaining to your project manager that this is not intended to be a perfect one. This is a first draft for that person to refine it later. So, you’re stating an assumption that person might not realise they might think it’s the perfect one and that covers all sides.

01:06:01 Sevcan Yasa: We have another question.

01:06:03 Sevcan Yasa: So, what methods find ways would Barbara advice to make the estimate and process more fun for the team? For example planning poker or any other fun ways of estimating?

01:06:13 Barbara Roberts: Playing poker’s grate fun we were doing pulling poker and we were using a boardroom that had glass doors and the owner of the company went past and was couldn’t understand where the team seemed to be playing cards and having a lot of fun. I do things like when we do planning poker, I make my teams plan in fruit because one of the things about planning poker is a point does not equate to a an hour or a day and it can’t be compared between teams.

01:06:41 Barbara Roberts: So, I’ll have one of my teams planning in bananas, so you know if our base story is a 2 bananas story, then this next one, how many bananas. So, a point equates to a banana another two will be estimating apples I do silly things like that. If you’re estimating a large piece of work at the early stages and you’ve got a lot to do planning poker and take ages. And what I put in the estimating course is the detail of affinity estimating, which is where you can do it on a floor in a room, assuming you can all get together and it’s much, much quicker to do a large volume of estimates.

01:07:17 Barbara Roberts: So, like you know, that’s all explained you. You put a story somewhere, then you pick another one, talk about it, put it roughly where it is, and then every so often you group them and you still end up with very, very rough planning poker groups. Please, please do not let people fill in the numbers between the Fibonacci sequence.

01:07:36 Barbara Roberts: That’s the whole point about Fibonacci sequences, the higher the gap is because there’s more uncertainty, so arguing for ages whether this is a 40 or a 38, no. If it’s bigger than a 20 and smaller than 100 or an 80, then it’s a 40 because bigger estimates will get broken down later anyway. You won’t take a 40-point estimate into a Sprint, and when you do bottom up estimating if you estimate 2 5-point stories and you do bottom up, they will look a different size. Because the top down is the story point, which is rough sizing, the bottom up is the most accurate and they won’t exactly map, but that doesn’t matter, it’s good enough.

01:08:21 Barbara Roberts: I just try and make it sort of lightweight, so again as a coach and as a manager, I make sure that there is no blame in planning sessions. None of this Ohh, for heaven’s sake. You know you’re always overestimating in my estimating sessions. I often make the project managers join in because I like getting them to justify why their estimates are smaller than everybody else’s.

01:08:44 Barbara Roberts: Why do you think that’s so simple? Then I always have a rule that you are not allowed to challenge a figure. You can just challenge the estimate, but basically in a planning poker session what you do is you do around, and you pick the highest and the lowest and you get the highest person. To explain why they think it’s so big and the lowest person to explain why they think it’s so simple. And usually, the difference is an assumption that hasn’t been stated. So, the one that’s very high might be saying, well, you’ve got all this to do and somebody else said, oh no, that already exists. So, you then write that assumption on the story and that is there carrying forward based on the assumption this bit has already done. We’ve already got a pay by credit card function ready done it’s going to it’s this big.

01:09:31 Barbara Roberts: So, it’s this sort of fun, but make it not personal so you know you don’t challenge the person you challenge. They’re thinking behind it, what makes you think it’s so big or why do you think it’s so simple. Because they you know, the two extremes are thinking something that’s different or they both know something that us in the middle have missed and normally it shouldn’t take more than three rounds to come to agreement. And if, say, you’re down to a mix between a 3 and a 5, just decide, you know, at this stage, would you rather go for a slightly higher one or a slightly lower one?

01:10:03 Barbara Roberts: It’s not about pinpoint accuracy, it’s about is it good enough for now because you don’t want to spend ages and ages doing planning poker. I’ve seen teams that take a whole day to do the playing poker in a two-week Sprint, which is just stupid. You know, we don’t have the time to be talking about doing most of our time should be spent doing at that level, the fruit one is great fun, Vicky. It really is, it gives everybody a laugh, but I find people if they say if even if mentally, they’re thinking that’s a day. Oh, sorry that’s a point. No, you’re not allowed to mention points. You just mustn’t mention them, you can mention points, but you can’t mention man hours on Mondays.

01:10:47 Barbara Roberts: Because it doesn’t equate and we, what’s interesting is if you get people estimating in bananas, they are so casual and they laugh such a lot about it and their estimates are better because they’re not thinking. Ohh, does that feel like a day or does that feel like and now they just go ohh. It’s well, it’s at least three bananas. And funny enough being relaxed about estimating, they’re just as good as agonising over it. You know, we’ve proved this over many years. The more you stress about it, quite often the worse it gets. So, I’m looking forward to barrage of fruit in all your projects now and people will think you’re completely mad, so you can tell them it’s my fault, but it does work.

01:11:37 Sevcan Yasa: We do have one more person in typing.

01:11:44 Barbara Roberts: That’s Carl.

01:11:46 Barbara Roberts: Will I be able to see the chat later so I yeah and then I can have a look at any questions that moved before I could read them because I’ve only got a little chat window here.

01:11:49 Sevcan Yasa: Of course, I can yeah.

01:11:59 Barbara Roberts: Oh, no different one, Carl is still typing.

01:12:17 Barbara Roberts: Yeah, I should do and also get some coloured baseball caps if you’ve not seen it, you’ve got the bonus thinking hats. It’s very similar so you have a Black Hat and a sort of bright cheerful hat, and you say, OK, you know, today you’re wearing the pink, cheerful hat. Try not to be so pessimistic but sometimes, as I say in my experience, usually my testers give the best estimates when we’re doing group estimating because they think about, they think more deeply, and they’ve probably been burned more in the past.

01:12:48 Barbara Roberts: Yeah, it does work the pessimistic and optimistic estimators and getting people to know themselves is the good thing about agile. You learn because you’re getting the feedback and that should mean that you do it. You gradually start to do things better and of course, if you do buy fruit for your estimating session, you’re helping the planet and helping people eat healthily as well. So, you might end up estimating with banana skins if they’re hungry, but the concepts there.

01:13:20 Sevcan Yasa: OK, thank you. If we don’t have any more questions, I am going to end the session. But if you do have any questions, you can always e-mail me, and I will forward over to Barbara. I’m sure she will be more than happy to answer them.

01:13:36 Barbara Roberts: Best I can. Yeah, as long as it’s not asking me to do your homework for your university thesis or something which I have had occasionally could. But no, I’m happy to answer questions and I’m looking forward to hearing something I haven’t heard before, a problem I haven’t heard before would be nice as well. Sadly, its people go through the same experiences, and they don’t realise everybody is going through this.

01:14:13 Sevcan Yasa: So, thank you so much everyone for joining. Just a reminder, next week you will receive the recordings. In the meantime, again, if you do have any questions about Barbara’s course, Barbara’s webinar or even our courses, you can always e-mail us.

01:14:33 Sevcan Yasa: Thank you, Barbara, very helpful. Getting very good feedback there.

01:14:40 Barbara Roberts: That’s good.

01:14:42 Sevcan Yasa: Few people are typing. It’s gonna wait for them?

01:14:47 Barbara Roberts: OK, I saw somebody was very unhappy, but it’s difficult to know what they came expecting. I think people that know me know exactly what they’re gonna get, so I’m very predictable if nothing else, and I don’t take anything seriously.

01:14:59 Sevcan Yasa: That can actually sometimes be a mistake, cause sometimes when I do look, they do give positive feedback. So occasionally we do get some negative ones but when I do look at the feedback, it’s positive, so I wouldn’t worry too much.

01:15:10 Barbara Roberts: It’s always nice when you’ve got four, though, cause people often look for the middle one just feels safe.

01:15:18 Sevcan Yasa: Which received the recording and slides next week. Thank you.

01:15:24 Sevcan Yasa: I’m going to start to end the session, so thank you so much. First, Barbara, and thank you everyone else for joining and hope you have a nice evening. Thank you.

01:15:36 Barbara Roberts: Yes, and a good bank holiday weekend, those in the UK and thank you all for coming and listening.

01:15:42 Sevcan Yasa: Thank you so much everyone.