Suggestions please

How does the outcome of estimates made in prior years are monitored and how does the outcome of those monitoring procedure is respond

Hi @Shah_Azhar, welcome to the community.

I’m sorry, I’ve read your question a couple times over, and I’m not entirely sure quite what you’re asking.

Can you give us some more information please?

i want some suggestions of how the outcome of project estimate prepared if we have some previous projects where we did not monitor any such outcome, and how to monitor that brief view.

I worked within the Scrum agile framework, so we guessed the 'relative ‘size’ of user-stories (place holders for future conversations about requirements) and started work. After 1 sprint, you have data about how fast you are actually moving, on this job, with this team and your relative sizes tell you how much you might achieve in the next sprint.

Estimating software is impossible because it is complex. You never know enough, unless you do lots of unproductive work, becoming more certain. Do productive work delivering something partial, of value, earlier instead and get feedback. It doesn’t matter what you estimated in the past, only how long a job of a similar size actually took. The smaller you split your jobs, the more sure you will be about how big they are.

There is a “no estimates” movement which just keeps splitting until every task is less than a day, then you count the tasks on the list. It is still a guess but you cope with the inaccuracy by delivering the most important things first, so they don’t care about the things there aren’t time for. Downside: they sometimes decide they don’t need things so you finish sooner than expected.


Shah, when posting on the web, please use useful titles. How about changing it to “How to use the outcome of earlier projects to modify current project estimates?”. That is immediately more useful to readers, both now and in the future.

1 Like

An idea I like that works at a slightly larger scale is to have a max project size - let’s say 6 weeks. If your team looks at a proposed project and it’s apparent that the estimate is going to be more than 6 weeks, you just don’t. Go back to your sponsor and say “we can’t estimate this. Let’s break this into 2 projects, each delivering some value, then we can give you an estimate for the first one.”

And in terms of estimating? I’m a strong believer in the idea that projects expand to fill the time allotted to them. The mantra that software is too complex to estimate accurately is absolutely true. But what you can do is say “it should be possible to deliver this XYZ in 4 weeks” …and then you will make decisions about tech, design, testing, etc along the way that will bring it in to 4 weeks. In a sense, you’re making choices about how much tech debt you need to accept to bring it in on time. If your original estimate (4 weeks) turned out to be “just right” then you’ll have little tech debt, if it turned out to be optimistic you’ll have a lot more tech debt.

This only works if you are a high-performing team given plenty of autonomy and management buy-in to your process. : )

Why not break it down into two week chunks so you deliver value earlier, after each one? The customer gets value (ROI) a month earlier AND two weeks earlier.

The problem with ‘projects’ is that they try to deliver ‘everything’ by an end date and no-one sees what it is going to be, in case ‘the requirement’ has been misunderstood or has changed, or indeed to demonstrate that progress towards the estimated date is feasible. What does 60% complete, marked on a Gantt chart mean? It means devs are optimists.

Everyone knows the last 20% really takes 80% of the time. I’ve seen a project that stopped because the money ran out, with the customer claiming what had been delivered was useless without the ‘work not done’. A big advantage of agility is that what is valued highest by the customer is done first, so the ‘work not done’ is things no-one cares about or didn’t even want. One of the biggest surprises to me was the rubbish people would put up with in the short term, in order ‘to have something’, quickly. “It doesn’t handle errors, just crashes” we’d say. “Then we’ll have to be careful what we type in. Just give it to us.”

We absolutely aim to deliver individual stories asap, but (and maybe this depends on the business) we often find that although there’s plenty we can show to stakeholders in demo after 2 weeks, 4 weeks, the actual feature is not fit to launch to our customer base until the first few stories are in place. In a sense I’m talking epics, I guess.

I also don’t see “the last 20% takes 80%” being true in practice. I’ve found with most of the epics/features that we build, getting to the point where the main path works is about 80% of the effort, filling in the various other scenarios and adding the ease-of-use improvements follows on fairly fast.

It won’t be if you are dealing in user-stories because they should be inherently independent and therefore deliverable. The (pseudo-)stat comes from conventional project specs where there is a m:m mapping from requirement points to design features, so there is no requirement for units of delivery to have anything to do with customer value.

If that were true, no-one would have felt the need to invent the term “epic”!

The reality in an substantial product is that a statement like “we want to offer customers a voucher giving them £20 off their first purchase” simply cannot be broken into 2 week stories that in themselves each deliver customer value.

Breaking it down:

  1. We’ve got to change our user sign-up process so that it issues a £20 voucher to every sign-up
  2. And we need to change our entire checkout process to allow for users with vouchers that they want to spend
  3. Not to mention we need our invoicing/accounting systems to understand what a voucher is and how to record it (and the spending of it) financially
  4. We want vouchers to have an expiry, so they don’t remain a liability on our books forever
  5. And we want to limit how many vouchers we issue in a week, as some protection against abuse

Now, I can instantly see that points 4 and 5 are not “MVP” - we can launch, and then add these stories in later iterations. But you can’t deliver points 1 or 2 to customers, you have to have built 1, 2 and 3 before there’s something fit to launch.

Okay, so you can say that 1, 2 & 3 are all one story. Yeah, I agree. That still doesn’t mean they can be delivered in less than 6 weeks. I know because we just did it (or something very like it). So whether you call it one big story, or a 3 story epic, that’s just semantics. It’s still 6 weeks before there’s something that can be given to customers.

But as you can see, we certainly had something to show stakeholders at every 2 week interval.

To me, this is the reality more often than not with many substantial new features. So when stakeholders say “we want to give new customers a £20 voucher to spend, when can we have that?” our engineer team need a way of giving back something more than the tired agile cliche “it will be done when it’s done” - then need to be able to say “we’ll get that done in about 6 weeks.”

I was comparing user-stories with conventional Big Design Up Front project management specifications.

Epics are based on the idea you can do functional decomposition of something that isn’t necessarily a function and that hierarchies are a useful model.

I don’t think ‘Agile’ is finished yet. We don’t understand enough about business value. Scrum washes its hands of it and lets the Product Owner decide what is valuable. We allow POs to say what they value highest. They tend to think it is whatever they want. As a BA, I’d say a voucher system is a solution rather than a business problem. We have to trust that the PO has done the necessary analysis. If we don’t care then we are probably working for us rather than the customer. I worked in internal teams where I sometimes had to tell my customer they couldn’t have things they wanted because they were poor value. Doing that was the reason I was recruited. Devs kept giving people what they asked for.

Some very good teams break everything down into 1 day ‘stories’ - probably tasks/features. I’m still trying to work out how they do that.

1 day stories? Interesting.

I certainly agree that agile isn’t “finished” but I reckon what it needs at this point is a bigger tent. We recognise the fault-line between business value and software development. But it’s naive to try and fix that by expanding the concern of the software engineering team to cover it; I don’t think it would be controversial of me to suggest that software engineers (and their BA/PO/QA colleagues) do not necessarily possess all the commercial acumen required to make the right decisions.

Agile needs to be embraced across all the functions of a business.

There are a bunch of companies out there “doing it right” but on the whole they are pure-tech product businesses (think Slack, or Basecamp) and so - surprise, surprise - the software engineers are able to look after the whole pie. Those of us in the muddier world of businesses where tech is only a part of the business model will have a tougher time of it until agility is across the board!

And, indeed, all the way up to the Board. : )

1 Like

Proudly sponsored by Bytemark