Estimates without estimates

Question

I have recently started working with a new large company, which has lots of different teams, working on different products, which are largely self-managed and are run quite differently.

My team is apparently "not using estimates", which, as initially explained to me meant that we have a "rough project delivery date" and "roughly planned sprints" with tasks "taking as long as they take". That sounded quite different to what I'm used to, but I figured, fine - these guys surely know how they work best.

The troubles are as follows:

• The team has 3 new team members, including myself
• I am not familiar with the tech stack of the team (this has been highlighted and discussed in my interview and was all good)
• After the first 2 sprints, it because widely known that we are "running behind schedule"
• The management are surprised in how long things are taking
• Certain tasks, including ones that I worked have "taken too long", even though they have not been estimated, broken down or discussed in advance

So at the end of 2nd sprint, I brought up the fact that we are mixing paradigms - we are "not estimating", yet somehow we are "behind estimates". I proposed estimating tasks and breaking them down, however that was met with push-back, since "it's ok to take as long as it takes".

And the end of 3rd sprint, I bought up the fact that part of the reason for things "taking longer than expected" is unclear, large stories, lacking acceptance criteria, with unfinished and changing designs, with new flows/features being discovered during development, lots of conversations with UX/PO and other devs about features mid-sprint, and proposed that we:

• Have backlog grooming sessions, where we walk through stories together, raise and discuss questions and break large stories into smaller ones
• Have basic story-point based estimation for stories (no need to go down to hours, etc)
• Have clearly defined acceptance criteria against each story, to protect against scope creep and allow us to better estimate

This was largely met with.. silence. People seemed to agree with the issues that I highlighted, but nobody really said anything about my proposed changes. I had a brief conversation with my manager and while my comments were met with good vibes, nothing concrete was said.

I chatted to a few of my friends, also in software development and they agreed with me, around this process or lack of being pretty "immature" and "problematic".

So I'm trying to figure out what to do next. Do I just.. accept it? Do I keep bringing it up? Should I bring it up with higher management and see what they say? Am I missing something here?

Just for context - I have worked in various Agile settings, from more or less standard Scrum, with story and hour estimates to Kanban, working top-down through lists of un-estimated stories. So I'm comfortable with different paradigms, I just feel like this team is mixing paradigms to it's own detriment.

Also this team and manager included all seem friendly and we all seem to get on, so I don't think that's an issue. The other new team member that I talk with quite a bit, shares my sentiments.

Keen to hear your thoughts!

Answer 1

This is not explicitly stated, but I assume you are in a software developer role, not a product manager or people manager (though my answer probably would work for a

So at the end of 2nd sprint, I brought up the fact that we are mixing paradigms - we are "not estimating", yet somehow we are "behind estimates".

This is not a contradiction necessarily. YOU (and your team) are not estimating, but someone else is estimating, so there are estimates. No project is getting started without someone having a concept of how much work it is. Unfortunately if there is no estimate from the engineering team, this estimate is just filled in by a manager who thinks he knows all the complexity, a lead developer or architect who is adjacent to the project or the product owner himself who compares it to "similar" projects she was involved with in the past.

I think you have identified the problem correctly and suggested good solutions.

This was largely met with.. silence. People seemed to agree with the issues that I highlighted, but nobody really said anything about my proposed changes. I had a brief conversation with my manager and while my comments were met with good vibes, nothing concrete was said.

To me this sounds like the people involved agree with you, but have no idea on how to move forward. You can help by suggesting concrete steps that you can do yourself, or coach someone to do:

Have backlog grooming sessions, where we walk through stories together, raise and discuss questions and break large stories into smaller ones
Have basic story-point based estimation for stories (no need to go down to hours, etc)

This is simple. You can suggest doing a grooming session, which you will lead and facilitate. Present a plan to your manager and ask a concrete question: "Do you want me to try this out in the next week?"

Have clearly defined acceptance criteria against each story, to protect against scope creep and allow us to better estimate

This is more difficult, since you need your PM to learn how to write better acceptance criteria. Ideally you can have a 1-on-1 meeting and give feedback on the clarity of the stories and give examples no how to improve them. During the grooming question you can also help by asking specific question about what is in scope and what isn't. Make sure to document the answers in the questions.

In summary: Don't wait for someone else to implement your suggestions. Do it yourself.

Answer 2

Even in the absence of explicit estimates, there's always going to be some anchor point in the mind of management, even if they accept that there's some risk of it taking twice as long, and a remote risk of it taking four times as long.

It's a common problem with non-technical managers not to understand how wide the uncertainties are, or to start relying on a estimate as if it was a certainty or a binding agreement. But it doesn't sound like that is necessarily the problem here.

It doesn't sound like your management are suddenly expecting magic estimates or a faster pace from developers. Rather, it sounds like they are merely expressing the fact that the project, and the sense of progress, is deviating seriously from their rough estimates.

They could react in several ways that don't require any change in your working method:

1. Cancel your team's project as failed.
2. Reorganise wider deadlines and expectations in the company - to accomodate a massive slide in the likely delivery date of your team's work.
3. Allocate more resources to your team in a sensible way - for example, allocating experienced developers from a project that is already safely home.

You don't say how big your team is overall, but "3 new members" involving external hires, together with an unfamiliar tech stack for at least yourself, suggests not only that performance will be seriously impaired for a while, but it (together with already expressing concerns about progress) suggests there was already desperation.

Your managers might be falling foul of one of the old Brookesian Laws, that adding people to late projects makes them later. Brookes said that in the context of otherwise sound management at IBM.

The exception to this rule is when management have already added several people to a project who don't even know the tech stack, let alone the subject area. In that case, immediately removing those fresh faces, and reallocating experienced seniors, probably does make the project move quicker.

Rather than suggesting new development methods or quibbling about the "estimate/no estimate" situation, the more appropriate conversation to have with your manager might be whether his rough estimate is consistent with the recent reconstitution of the team.

Answer 3

I've been in the same kind of scenario where for sake of speed/velocity and deliver things quickly we were not spending time on backlog grooming and sprint planning. It works well for couple of sprints but in long run team members start getting frustrated because they were just working without any roadmap and clear picture. I second all your sentiments and suggestions. It's clear that higher management have timelines in their mind and they are expecting development team to follow those timelines but seems like unfortunately those timelines are not clearly communicated to development team or development don't understand importance of prioritizing and estimation of task.

Biggest hurdle which I beleive here is taking first step. I guess everyone in your team are aligned with your thoughts but not ready to start. As scrum looks very simple but it's implementation is very difficult. Some large organisations tooks very good amount of time even to start following scrum. I feel same is the case with your team. I would suggest you to take step forward and start estimating/planning and prioritizing task in sprint on your own and take ownership of this. After a sprint or two I hope everyone in your team will start realising the output of your efforts. Next step will be make this process part of their habit. I agree it's not easy and not a matter of weeks. Implementation of this could take months or more. But in long run this effort will make your team less prone to missing deadlines and also make your team autonomous and self organized.

Answer 4

You are getting caught up with the problem and not reading the human side of things. Let me translate

• Rough Project Delivery Date : Deadline that we have told the customer.
• Take as long as they take : You are not allowed to cut features to meet the deadline.
• Not doing estimates : We don't want to hear that you think we cant make the deadline.
• Running behind schedule : Not working over time.

Now. If your boss was more forthright with you and said these things, their problem becomes clear:

• They have promised to deliver X by date Y and are worried they aren't going to hit it.

All your proposals about estimation and planning DO NOT HELP with this problem. You are trying to fix the wrong thing from your boss's point of view.

How can you fix The Boss's problem?

1. Work overtime.
2. Cut any feature that isn't explicitly called out in the spec.
3. Cut corners on meta work, CI pipelines, documentation, meetings, demos etc
4. Find external reasons for the delay ie. customer hasn't provided X on time.
5. Integrate with/use off the shelf solutions

Obviously this is not advice you are going to get from a forum about best practice and excellence in software engineering. Do you really need to be told these things, or are you just venting?