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!

  • 2
    The amount of work and the time it takes does not really change in your proposals, at best it becomes a bit more structured, but could result in lower quality software (it does what the specs said we made up a while ago). What is the problem you’re trying to solve? Being able to tell managers sooner that their expectations are unrealistic?
    – Rik D
    Commented Mar 19, 2023 at 7:43
  • Are there any commercial consequences to the schedule? "real" deadlines typically exist for commercial reasons and have severe commercial consequences which the team would hopefully be made aware of. If you are fortunate enough not to have such deadlines then this is an advantage which means being less likely to have to make decisions about compromising quality or developers working longer hours. If management are happy with "as long as it takes" then I doubt anybody will thank you for trying to convince management to start holding your team accountable to artificial deadlines. Commented Mar 19, 2023 at 8:11
  • The problem I am trying to solve is the mixed messaging within the team about whether we do/do not do estimates, which occurs due to us not doing any sort of backlog grooming/estimation/exploring stories prior to taking them into sprint, which results in us not having any sort of calculated velocity, which means that our PM/POs pull out project estimates out of thin air, which then seems to cause the team to "run behind schedule", even though that schedule was simply guessed. There are "some" commercial consequences. I'm all for working without estimates, it's just it seems mixed..
    – Web Dev
    Commented Mar 19, 2023 at 10:01
  • ..within the team. While they are saying that we don't do estimates, they are also asking people to estimate tasks, which are then put into sprints, which then seem to run late. And it makes sense too - how can anyone "estimate" tasks, without "estimating" tasks? The approach actually makes no sense at all and I called it out, but nobody could explain it clearly. Both myself and the other new guy are equally confused and frustrated.
    – Web Dev
    Commented Mar 19, 2023 at 10:03
  • 3
    This is a team culture issue. There is no software engineering practice or pattern that will fix this. Unfortunately you have a "people problem," which is a better fit for The Workplace. Commented Mar 19, 2023 at 14:43

4 Answers 4


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.

  • 1
    "To me this sounds like the people involved agree with you, but have no idea on how to move forward." - that's very much the sense I've received, too.
    – Steve
    Commented Mar 19, 2023 at 12:23
  • Thanks for your feedback! I actually chatted to a few other senior members of the wider team and have received mixed and somewhat confusing feedback. One team member suggested that it's extremely important to break large tasks down into smaller tasks, but when I suggested that this is why rough estimates can be super useful, they replied that all break down should happen without estimates, which sounds... strange. Surely estimates and break down tasks/refining backlog should go hand in hand?
    – Web Dev
    Commented Mar 21, 2023 at 11:31
  • 1
    @Ross It is a valid approach to just say that you break down tasks until they are small enough. Then you can just use the number of tasks for estimation. How do you decide what is small enough? Maybe what a single developer can do in one sprint, or something like that. Congratulations, you just introduced estimates through the backdoor. Don't get too hung up on it, if that is what you can get everyone to agree with this is a good start. You can always introduce more detailed estimations when things catch on and you have proven the value of doing basic grooming.
    – Helena
    Commented Mar 21, 2023 at 20:41

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.

  • Really good points Steve! I definitely agree that adding or removing team members can have a significant impact on how a team works. This current team is around 10 team members. I did point out the impact of adding new team members a number of times, which was met with positivity. I also pointed out that support from outside of the team has been quite minimal. The last bit of info I received was that instead of estimating in story points, we should be breaking our tasks into 2-3 day long tasks.. individually, after committing to larger stories at the start of the sprint. Seems a bit crazy.
    – Web Dev
    Commented Mar 21, 2023 at 11:37
  • @Ross, are they suggesting that to you as a productivity measure to improve their delivery forecasts, or are they just offering that to you as a specification of their normal working method? In other words, is their suggestion to you that you work in a particular manner related to their complaint that things aren't progressing quickly enough, or are these two separate complaints on your part (one of your complaints being about their undue complaints about slow progress, your other complaint being about their usual working methods)?
    – Steve
    Commented Mar 21, 2023 at 12:22
  • I think that is a specification of their regular method. I'm 100% on board with breaking tickets into smaller tickets, it's more how it's done that is the issue. I'm getting different pieces of advice, depending on who I talk to, which just adds further to the confusion. For example - when I got the single large ticket assigned to me in sprint planning I got a "do you think you can finish this in two weeks?" asked of me, to which I said "maybe?". But some other devs expect that ticket to have already been broken down by me at that stage, even though that's the first time I saw it..
    – Web Dev
    Commented Mar 21, 2023 at 23:42
  • ..so my suggestion is to introduce backlog grooming, so by the time we have tickets in sprint planning, they are already broken down, have clear acceptance criteria, etc, however, I got pushback on that, saying I should just do it myself. I questioned that, since I don't actually have the visibility of what happens the sprint after, to break tickets down in advance, which is exactly why I think backlog grooming is so useful. I seem to get different advice from people, when I talk to them individually, but talked to the group resulted in basically no feedback. Weird! I'll keep trying!
    – Web Dev
    Commented Mar 21, 2023 at 23:45

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.

  • I think that sounds pretty much extremely similar as to what's happening in my team. I think the biggest concern I have is how much push back I'm getting on rough estimates. It seems that people are on board with breaking stories down and defining clear boundaries, however people do not seem to want to estimate or have backlog grooming sessions. It's .... weird.
    – Web Dev
    Commented Mar 21, 2023 at 11:33
  • 1
    This is common all around the globe. Becuase usually developer runs away from documentation or relatively non technical things like backlog grooming, sprint planning, learning better approches to estimate their work etc. They thinks only coding is part of their job. So, making people realise the importance of backlog grooming and estimation is tough and time taking work. This will help if you set your team OKR to do any certification on scrum. Commented Mar 22, 2023 at 8:21
  • 1
    Also, you will only be able to have regular backlog gromming session if you have product owner and scrum master in place. Otherwise no one will take additional responsibility of keeping backlog groomed. Commented Mar 22, 2023 at 8:22

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?

  • Thanks for your feedback! I'm half venting and half seeking advice. The culture of this team has been quite positive. Suggestions are welcome, working overtime is discouraged, work life balance is strongly emphasized. This makes me think that overtime and burnout is not what the management is after. The team is also made up of talented and driven individuals. I honestly believe that process is in fact the main issue. I've never worked in a team where the simple suggestion of "estimates" brought a general quiet and a feeling of discomfort. I wonder if I'm missing some history there...
    – Web Dev
    Commented Mar 21, 2023 at 11:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.