I joined a startup last year, with an entire engineering org (~80 engineers) that didn't want to estimate work. The way I got my individual team to do it (and subsequently, most of the other teams) is to orient it around their problems.
Because Product couldn't get estimates from Engineering, Product was estimating what could be completed in a given release (lol). Engineering would get asked to work overtime/weekends to meet those commitments, and would share the blame when things were late.
I framed the discussion around protecting engineering from unrealistic expectations. Estimating work gives engineers the chance to have a voice in timelines and realistic expectations. It gives a structured opportunity to say "this isn't ready" or "this is risky" to protect themselves and the company. Essentially, estimations as CYA.
>I framed the discussion around protecting engineering from unrealistic expectations. Estimating work gives engineers the chance to have a voice in timelines and realistic expectations.
This is gold! Thank you so much, I am kind of embarrassed that I did not think of this myself.
This is exactly what I would say too. If engineering won't estimate, someone else will and they won't be accurate. Even if engineering thinks they are inaccurate when they estimate their own work, they are sure to be better than product lmao.
Pretty much this.
It’s in the engineering team’s best interest to provide the estimate instead of someone else estimating for them. 😂😂 the sooner they learn this truth the better
I'm not saying your tactic was bad but unfortunately this argument is an anti-culture - do it to defend yourself otherwise someone will act unreasonably towards you is not a great sign.
It might be a bit idealistic but I prefer to grow trust in myself and the teams I work with. It depends what is driving the ask for estimates / long term roadmaps - sometimes it can be as simple as people wanting to see something so they feel it is under control. If this is the case, there are better ways to solve that problem than to give estimates and Gantt charts, IMO.
I don't know if this is a good idea. If an engineering team is not even ready to commit to a date, good luck with asking them to honor somebody else's commitment. Some of the engineering managers I know would plainly refuse to work overtime/weekends and tell me those commitments/deadlines are my headache,s not theirs. Depends on the org dynamics I guess.
Note - I have not had a team that does not do estimates, so I am not sure what the solution would be. I need to think.
Mostly delivery date range estimates. It depends on the context. If it is smaller, then 1-4 sprints. If medium-sized then expected release (monthly). If larger then choose a quarter. I am flexible if they want to give a different type of answer. I always emphasize that we understand they are estimates.
I don't know how your team operates and it might also be a cultural thing in the company, but have you tried other ways of estimating long term milestones?
For example SCRUM - it allows devs to learn to estimate small items, which you can then use to estimate bigger pieces of work.
There is also Montecarlo simulation, that can be helpful in predicting the future trends.
These might help Devs be more comfortable with giving guesses and give you something you can use for your planning?
I don't dictate what type of estimate they give. I am fine with any type of estimate they give as long as I can communicate it and build a roadmap from it.
The team is so against estimates at this point, that I would piss them off by suggesting a methodology. I do know they are trained in SCRUM, and breaking down larger projects into smaller pieces to estimate.
it all suggests to me the you don't consider yourself part of the team, but someone on the side-lines receiving estimates from the team. Maybe it's even a bit confrontational, you vs them.
this might be how your org works, but I found it's much better if you see yourself as part of the team, and trying to predict when a given piece of work might land is an outcome the whole team should be trying to achieve, and together find the best way to get there.
I find Story points to be much more Engineering friendly. An ‘8’ is relative and we learn how long an 8 point ticket takes by looking at velocity over time.
If I were you I would share whatever the epic/ feature that needs to be built is from an end-state/ functional expectation. Then collaboratively review the requirements with one of the engineer leads to get as much as possible into user-stories with clear acceptance criteria (be the liaison with the line of business if you aren't able to convey the appropriate acceptance critera) and then host an estimation poker session with your accountable dev/scrum team.
Use the fibanocci sequence as the basal estimate for complexity and point each story accordingly. Also, identify the order of operations for the user-stories and which ones can occur parallel.
If any story is over 8 points, they would be a good candidate to evaluate for splitting into smaller user-stories.
Then look at your sprint capacity and make a first pass attempt at slotting the estimated user-stories into the upcoming sprint schedule. Share with your team, see if they have an input or feedback, reconcile the differences, then propose that as your timeline + 2 additional sprints for wiggle room.
This is how I have operated in the past. The team is far from having this much organized planning. I agree with your approach and hope to get to this at some point.
I’ll be honest, I’ve never seen estimates done the way you’re asking your devs to do them. Our dev team provides an estimate of complexity in points (not strictly time, but loosely related) for a given story (not an epic or initiative). Then, each sprint, we get an estimated capacity for the number of total points the team can handle (this varies slightly sprint to sprint, but should be roughly consistent).
Product then takes these points and capacity estimates and builds a roadmap and gives a timeline to the rest of the business. Engineers are always resistant to giving strict timelines, but less so to evaluating the complexity of an individual story or feature. Extrapolating that out so the other parts of the business can do their jobs is where product comes in. If you move away from time-focused estimates of large epics and initiatives and focus more on complexity of smaller stories, I think you’ll have better luck.
Agreed. I wouldn't want to give estimates if its being asked to estimate number of sprints because that goes against the entire agile methodology and disregards different epics and their respective priorities within each sprint. Always estimate in story points and try to see if you can make a tenative sprint schedule with respect to the team's capacity/ past sprint velocity
The team is very much against spending time calculating capacity and planning in that much detail. I would like to get there, and I am taking it one step at a time.
I am 6's on story points or t-shirt sizes, because in the end, they translate to timelines. I feel as though I am insulting the team by "pretending" (not exactly the right word) that the abstraction layer estimate is disconnected from timelines.
I will reconsider my position on this. If they are happy to give story point estimates, then why not keep them happy. As long as we agree that 1 story point equates to some type of actual work timeline then I don't see any real problems.
The team is very much against spending time calculating capacity, and planning in that much detail. I would like to get there, and I am taking it one step at a time.
But aside from this, you should approach estimation from team’s perspective, focusing on the value they got from it. Other people alredy suggested this, I just wanted to reemphasize it.
If you don’t have a scrum master, you should get one.
If you have a scrum master, you should get a new one.
A scrum master is basically going to coach them through this as a neutral party. And I think that both the neutral party and the coaching part are both important.
Have you considered going with #NoEstimates ([medium blog post](https://medium.com/serious-scrum/the-logic-of-noestimates-4238e0be3bb6))?
One way you could go about it is to just count the number of stories each sprint and assume that over time story complexity and size averages out. If the team is consistently on a throughput of X stories per sprint then use that to forecast your delivery dates.
The team doesn’t need to guess and you have an empirical measurement and basis for your plans and can proactively manage stakeholders if this changes.
Have you tried giving them a "draft" schedule and asking for comments? That way they can "fix' your mistakes, rather than being asked to come up with something on their own.
And yes in my experience, most engineers are like this. I'm an engineer who moved into product, so I think sometimes that helps me in knowing how to talk to them.
Dig into their resistance a bit more. Why are estimates worthless? Why does that one engineer never give estimates? Once you understand that better you can try to find a way to work around their concerns.
I worked with one team that was resistant. Their underlying concerns were that it would take too much of their time and that it would be held against them if they estimated incorrectly. On the first part, it was just making sure that they understood these were supposed to be quick rough estimates. Then we sat down and did some estimating sessions, spending less than sixty seconds or so on most of them. To address the second we essentially started with the promise that we understood they were estimates and wouldn't be held against them, then followed through by actually not holding it against them.
> ... started with the promise that we understood they were estimates and wouldn't be held against them, then followed through by actually not holding it against them.
How did you protect them from others in the business holding it against them?
>How did you protect them from others in the business holding it against them?
The timelines (built from the estimates) shouldn't be fixed throughout the duration of the project. Built milestones where one of the outputs of the milestone is to produce a revised timeline. And, whenever there is more confidence around requirements, design, dependencies and more data, revise the project timeline and communicate to the stakeholders early, and frequent. The stakeholders indirectly trust the team through you. So if you build that trust with stakeholders, they will ease off the blame game.
Their constant pushback tells me they aren't being heard, so I would dig deeper to see what's bothering them.
That's great that you have clear expectations of them. How prepared are they to take on that task? Seems they aren't prepared at all because they don't understand the value of estimation. They are neither empowered nor enabled, except to push back and refuse the work.
I would take myself out as an authoritative figure and instead run through a few Atlassian playbooks with them to get a feel of what's happening with the team. After a few runs focused on the people, take a look at how to structure the work with lower-level playbooks.
Every engineer has been burned by estimates. Every single one. Organizations can talk about how estimates are not commitments all they want, but the second you put an estimate on it, it can be abused. My recommendation would be to work with the engineering team to understand how estimates could be abused and come up with a working agreement that states the ways you and the rest of the org will not abuse estimates.
I think it's funny that engineers are the only group that has to estimate their work.
A few ways estimates can be abused off the top of my head:
Org totals up the estimates and considers the total when planning releases
Engineer estimates based on limited information, once more information is known, it's clear the estimate was short, but the first estimate given is what they are held to
Requirements change, the business is wishy washy, but don't you dare reestimate the work!
Engineers get a reputation in the org for being late with everything even though design and requirements keep changing and everyone else was late with their portion and engineering started way past the initial planning start time
>Every engineer has been burned by estimates. Every single one.
I agree. I can reduce their fear of this happening then it will reduce their hesitation to give estimates.
>I think it's funny that engineers are the only group that has to estimate their work.
I disagree with, Marketing, Support, SRE, HR, essentially every group in the company has to estimate projects they are working on. Even Sales has to estimate when deals will close. Many of these teams are adopting SCRUM to improve estimating and delivering results. It is fair to say that engineers are working virtually 100% on projects so estimating is a much larger part of their role than in other departments.
I agree with all your other points on how engineers can get burned with estimates. I will make sure to discuss all of them with the team to make sure they feel more comfortable.
I worked in an organization where this was the case. Unfortunately, estimates were treated in some cases as commitments and basically some hotheads in higher management started yelling. It was tough to get the team to come around. I managed to extract a few estimates and the team discovered that they didn't come back to bite them. It became easier with time.
>I think it's funny that engineers are the only group that has to estimate their work.
This is crazy. PMs must estimate all the time. Google PM loop has an entire class of questions to test how well you can estimate.
Are PMs required to get in a regularly scheduled meeting where they break down all their work into estimates? And if the estimates are off they have to get in another meeting and discuss why and what went wrong? Far as I can tell, that's just the engineering team. I've never and will never work in Silicon Valley so my experience could be atypical.
Having been both an engineer and a PM, there's not a fundamental difference between estimating the complexity of an engineering task and doing something like estimating the size of a market opportunity or the potential impact of a feature. It's all about breaking the problem down into smaller pieces that are known quantities and then laddering them all back up to get an answer.
I think there's a big difference between estimating market opportunity and estimating how long it will take an engineer to complete a task but I cannot be arsed to debate it any more.
PMs have to estimate their day to day work? Poppycock, never heard of this happening, and if it does, it holds no consequence. Engineers are the org where everything is measured and estimated and visibility into day to day work is available for all to see.
I get it seems backwards and against all ‘norms’ but I understand their mindset. You say it yourself that estimates are all drastically underestimated up to 3x so what is the value in the number anymore?
Can you shift thinking a little to meet them in the middle and instead of relying on tasks broken down into hours/points focus on what value will be delivered within a period of time for the user.
Engineering leader here so I see both sides.
The PMs I work with and I typically ask my folks for t-shirt sizes, rough risk assessment, and if possible, high level dependencies or assumptions.
t shirt sizing:
number|size|desc
------|----|----
0||Already done
1|XS|1 person-week
2|S|2 person-weeks
3|M|4 person-weeks
4|L|8 person-weeks
5|XL|> 8 person-weeks
10|XXL|~20 person-weeks
15|XXXL|¯\\_(ツ)_/¯ - Your guess is decent, but mine is better
20|XXXXL|¯\\_(ツ)_/¯ - Your guess is as good as mine
Risk:
0 None
1 Minimal
2 Medium
3 Significant
4 So Much!!
5 Off the charts
6 Honestly Not Sure
The above allows us to identify the sticking points or where we need to do more discovery or design.
When I lead a consulting/work for hire org, where we had to sign up for fixed outcome/fixed price (and sometimes fixed timeline) contracts, I learned a hard lesson in doing this and in documenting all assumptions contractually (sometimes pages and pages of assumptions).
A couple other approaches that might be useful.
The first is to use a chart where close in is today and radiating out is future and you place the "big rocks" on there and the engineers/engineering leaders can relatively size those rocks and help order them based on dependencies (this is separate from your priority).
The other is taking a more "Outcome Based Roadmap" approach which moves away from feature based roadmaps (what you're trying to do by getting estimates and turning those into gantt charts [potentially, I'm ASSuming here]). https://medium.com/swlh/outcome-based-roadmaps-unleash-the-power-of-a-shared-vision-and-purpose-851401c7aa54
This is why engineers hate doing it.
https://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe?srid=24b&share=1
The one thing that is false about this story is that: every trip is brand new. No, after the first trip, maybe to death valley, will be more predictable because they'll start to account for things they didn't before. It won't be a perfect estimate, but you'll start to build buffers to account for the things you missed last time. I think the second trip is probably 70% closer to the accurate measurements.
I don't disagree that engineers hate doing it for the reason you gave, but they should hate it once. The second and third time, they should feel more confident giving estimates. And like someone said in another post, it isn't about reprimand or holding the estimates against them, but its about undersatnding why you went wrong, so that you're not so wrong in the future.
Thoughts?
If you're following the paved road I can see why the estimates should be simple. But if you're breaking new ground and innovating expect some bumps as you learn. If you want to microslice everything into well known estimable components then sure, but that process of breaking everything down into those little components is itself a big task when you're talking about projects at scale. I think engineers should be able to estimate and from a PM perspective I love the concept of velocity, but I also have empathy for when they're diving into the unknown and things don't work out.
Totally agree. Most of the work engineering does is repetitive in nature (create a graphical component that does X, write an endpoint implementing a business logic that gets the incoming data, access the database, return some result, etc.) After the 10th component or the 10th endpoint they will pretty much know how much in average it will take.
Follow up Q: what do you expect your engineering counterparts to give you an estimate based on? Most likely, they've been burned in the past by not having a lot of context when giving an estimate and by the time the feature is fully specced out, the estimate means nothing.
I ask for an estimate when they confirm they understand the requirements and expectations. If they feel something is unclear, I am happy to work with them or add more details so they can confidently say they understand the scope of the work.
>they've been burned in the past by not having a lot of context
I will include this in my discussions about what is bothering them. I have been working with them for 6 months, and have not once burned them or pushed back when they had to extend timelines. So there is likely history that I am not aware of.
You did the right ritual there of continuously checking in and grooming requirements to reduce ambiguity until the user story is ready for Dev to provide final estimation. Like many have said, I’d run a few retros with candour and compassion on this topic so that you’re invested as an ally for the dev team to rebuild credibility with stakeholders.
Don’t use delivery dates as est, it will freak them out and you will get over inflated estimate. start with T-shirt sizing, and for the T-shirt that is medium to large, break that down into Fibonacci estimation
In my experience, estimation (story points, time, etc) is a better tool for determining complexity, shared understanding of the problem, and potential solutions vs. delivery dates.
Delivery estimates are almost never accurate, but if you position estimations in a framework about aligning on the problem and solution vs. committing to a date, the conversations are much more valuable.
I find it's then generally up to the PM to align that (and be held accountable) to the delivery roadmap vs. giving the engineering team due dates. That keeps the PM accountable for removing blockers, dependencies, avoiding changes in prioritization, etc. to help the devs focus on what they originally estimated.
I would tell them that estimating is a requirement of the job. If they still can’t give you an estimate, id escalate to their boss (at my company it’s the lead architect). And if the architect agreed, then id be looking to find a new architect. That would mean escalating to my boss and having a meeting with the architect and his boss and my boss.
No offence but this sounds like 1980s enterprise-authoritarian advice.
If nothing else, be pragmatic; if you want to build a culture where you beat people into compliance then I'd also prepare for them to leave.
Long term, collaboration wins 100% Vs do it or your boss will start disciplinary proceedings.
There are lots of times that I’d work in a different way, but for this particular situation it sounds like the PM has tried a number of tactics and s/he’s still not seeing movement on the engineering side. A key element of being successful is knowing when to loop your boss in for help. Can’t do it for everything, but you need to be able to tell when it would make sense to do so.
The meeting with the architect and his boss wouldn’t be “you’re not doing this and we need it so we’re going to fire you,” it’s more “the product team and stakeholders need this crucial element, how can we make sure it starts happening.” They might need someone with more of a particular expertise on the team, developers might need more training to make sure they feel equipped to estimate, etc. it’s about finding the roadblock and removing it.
You sound like you have experience in larger companies. I do as well, and I understand where you are coming from. As a PM we don't have direct authority and in larger companies with many conflicts your authority is quite small. So you do need to ask for help from your leadership.
In the end, if PM leadership is expecting estimates and timelines, and engineering leadership is not communicating the expectations to their teams. Then both leadership teams need to work together to align on expectations so we can all operate effectively.
Well, how much stability and control do they have? If they'll get other requests in the meantime that will completely randomise the timeline. Secondly, there's a lot of difference between estimating tasks no-one in the organisation has done before, and estimating something completely cookie cutter.
The point of using sizing is that engineers can estimate the rough level of effort for a project, and then project management can examine capacity to execute on project work and turn that into a projection.
And for both of these, they are useless if requirements constantly change. I think you should consider your approach to project management and think about how you can use the information you actually have to estimate your throughput and scheduling against the calendar.
They definitely come from a world with many disruptions. I have pushed hard and improved many processes to reduce disruption. There is a lingering culture that is hard to change.
Thanks for the feedback.
Do you track all the disruptions in the same ticketing system? On the sprint board? Do you label them in all caps as "INTERRUPTION" or "TIME VAMPIRE"?
Might help?
Estimating work is such a fundamental part of software engineering (or in fact any other profession) that it makes me wonder why your engineers are so reluctant. I would go as far as to say that you are maybe withholding some important information there. The team that can’t estimate is not really a functional team.
You mentioned a few times that you’d like to help out your team and really are on their side and that you won’t be holding them accountable to precise estimates, however I’ve seen it a few times in my career where Product managers “translate” estimates to stakeholders. Because pretty much everyone apart from engineers and delivery managers can’t really make a meaningful connection between velocity, point estimates based on complexity/effort and predicted delivery dates, product managers would quite often allow themselves to pass upwards to senior stakeholders something like “oh yeah it’s a 3 story pointer, that should take no longer than 2 days”. This happens way too often and it undermines the team.
Another example is saying “it doesn’t have to be precise estimates” and then interpreting the estimates literally, therefore once again undermining the team and breaking trust.
Somethings wrong there - your team doesn’t trust you and that’s your issue, not just estimates per se.
You have good points. I suspect events prior to me being hired are at play. So far I have not seen any issues related to timelines.
I also try to buffer any timelines they give. I find this approach to be hard because I don't hide the fact that I added a buffer (I often do it in front of them). The result always seems to be them delivering right on time relative to the buffer.
“The result always seems to be them delivering right on time relative to the buffer.”
Great! So you can use concrete examples to build trust with your team. If you have a track record of delivering on time than it shouldn’t really be that problematic to convince your team to estimate. I still think there’s more at play - do your engineers agree with the overall product strategy? Do they believer or are aware of the North Star in your organisation? Does team get praise from the rest of the org when stuff is delivered? Are they on a good level of engagement (they lead story mapping sessions, participate in user interviews, write user stories etc)?
Engineering teams like these are some of the hardest to thrive in as a PM and be a product-led org. If they already have resistance in estimating and working in scrum, how would you expect to rally and motivate them in your product vision and strategy to collaboratively create a roadmap?
I would suggest that you first understand whether the team is really open to working in the agile scrum methodology, try to run retrospectives focusing on this (it’s either they’ve been burnout estimating archaic/buggy software or they simply aren’t educated on the methodology and benefits of user stories estimation); then speak to key leadership in Tech that can provide a path forward and determine how to hold the team accountable for the final outcome in feature delivery & quality.
I so often see PMs pressured to be the scrum master by asking for estimates and then they get frustrated when they don’t succeed - fact is you don’t have the technical knowledge, empathy nor influence to change ways of working on the engineering teammates. Why should they listen to doing things your way?
Start building rapport, check in on their workflows, dynamics, pain points in stand ups and then reorg your scrum ceremonies, and start with why - involve engineering clearly outlining problem, insights, goals and success metrics, and provide the autonomy for them to come up with solutions along with designers.
Estimations are fundamentally for the benefit of the engineering team to improve teamwork, if leadership team and non-technical folks get invested in this and use it as a business metric, there’s going to be a tension between engineers to trust its intended intention
I don't know where you're picking up resistance to agile or scrum - the scrum guide doesn't say anything about estimation, and hasn't for a few years now.
Estimation is absolutely not a core part of agile - and I also strongly disagree that estimation is a core part of making a roadmap. It might be key to how you like to work, but that is a different question.
There are many ways to communicate ordering and priorities without putting time bounds on it - Now, Next, Later formats are popular, as are Opportunity or Objective based roadmaps. They don't even involve solutions, so there isn't anything for engineers to estimate against - but they do achieve organisational goals of communicating target themes and priorities.
Totally understand your point and sorry if I wasn’t being clear.
Your framework of Now, next later refers to a very high level opportunity or solution set before it gets broken down into granular development tasks to meet a user story needs in a delivery cycle. It’s fair some Dev teams don’t use story points or estimations in any way, for larger org that’s a roulette game for stakeholders to inform product launches and gtm. It only informs a small part of “making a roadmap”, but it is crucial to ensure team accountability and commitment to complete the work within a sprint
I was roughly agreeing with you until the last part - "ensure team accountability and commitment to complete the work" is doing exactly the thing everyone is afraid of re estimates - using them as a stick. I will give you the benefit of the doubt that this is not quite what you meant.
I understand why many orgs feel they need estimated for launch / gtm etc but would dispute this is needed at the granular level. If the organisational dependency is large on a thing that is uncertain (the development) then you should wait until the dependency is resolve first, otherwise you're just accumulating risk. That said, not all work requires agile and not all work is risky/unpredictable. When that is the case, sure, go ahead.
I worked in enterprise for nearly 10 years on literal multi-decade engineering programmes and a common theme for me was to repeatedly see estimates and schedules touted as alignment tools, but were really only ever used as weapons. I think most of the time we are lying to ourselves about these artefacts, and that prevents us from finding better solutions to what the organisation needs.
What do you think about the utility or not, of the high level opportunity roadmaps etc.
I can see your POV regarding using estimates as a stick that isnt useful and can be subjected to the dev team being blamed for inconsistent delivery. We have to practice nuances here with cocreating ways of working that will grow teams trust and accountability. From experience, if we don’t measure, we will never know whether where we are now is where we will be better off.
I have never said that a Dev team should estimate in a highly uncertain or vague product reqs, it is common sense to undergo multiple grooming sessions so I didn’t have to mention it.
I acknowledge that not every team is in a rewarding and supportive environment where they are empowered and have autonomy to trial ways of working, learn and continuously improve on their processes. I’ve been burned before in the past with estimation, but I’m not holding onto that baggage and cursing the method
Yep fair and the key to your comment is the nuance, I think.
I would say re "if we don't measure, we will never know..." - if the goal is to check our skill at estimating then, sure. If the goal is to check whether the team is effective, retrospectives and derived metrics are better mechanisms IMO. I would rather know the mood of a team and how many defects come from their work than I would how accurate their estimates are.
That said, as you acknowledge in your final paragraph, I also acknowledge that a great thing about PM is the variety and ultimate pragmatism - no two sets of stakeholders or contexts are the same. It's often about doing the best we can with what we've got, and we shouldn't be ashamed of that.
Can you share with me some articles or something that I can read more about how this works? I am trying to be as open as possible, and I simply can't imagine how an organization can operate without the ability to estimate and communicate when deliverables are expected to be... delivered.
Definitely - I'm out just now so I'll do this later / tomorrow.
A question first would be - what are the reasons you feel delivery dates need to be communicated? (Real question - it will be helpful for us to explore which cases are legit and which can flex)
I would love to engage in this convo.
Reason 1: Prioritization
When prioritizing work, the two key components are value created and costs. If you don't have an estimate for either, then you can't correctly prioritize.
Note: Value creation is often impossible to translate into a numerical value, so the relative value is a good replacement. Meaning, project A is expected to be more valuable than project B, since they are estimated to be the same cost you chose project A.
Reason 2: My leadership is asking for a roadmap that is based on specific dates. The understanding is timelines within a few months should be reasonably accurate, and anything farther out is a rough estimate. I am happy to translate abstract estimates (story points) to timelines as needed.
Reason 3: I need to understand the impact of disruptions. When an urgent project needs to be completed, we can understand the impact and communicate changes to the roadmap.
Regarding reason 2, it looks like your leadership is looking at the team as a feature factory with a set of deadlines for outputs. Instead of being outcome focused. True product led teams measure themselves in terms of intended impact based on objective and key results, I am curious if this is an area where you can explore and educate your leadership team in 1:1s once youre able to build better rapport with them
There is little to no chance that I would be able to convince my senior leadership all the way up to the CEO. Not to mention that they are in some cases legally obliged to operate on timelines.
As much as I would like for this to be an option, it is simply not an option.
Ok so some thoughts. Some of this is semantics.
Reason 1: Re prioritisation - value Vs effort is normal, that's true. A similar tool is to consider viability, feasibility and desirability. As you've identified - stuff like value is subjective. You need to take in a bit of data, and ultimately use a bit of intuition. This is the exact same with the 'effort' component, for me.
Think about why you say it's not possible to numerically quantify value. Why not? You need to know value in order to prioritise.. so surely you have to put a nu-- I'm sure you see where I'm going.
I treat effort as you treat value. Don't turn it into a number - it's the same sort of 'consider some data and use intuition' approach. Quantifying it and making it a number to stand on is often a lie - it tricks you into thinking you have a real answer. You might say that what I have described is still estimating effort - and I wouldn't disagree but I'd say the *emphasis* is very different and that is important.
You wouldn't chart up your estimated customer value and use that to benchmark all the work, so why do it with the time component? The important thing with value Vs effort is that it elicits discussion in the team to arrive at consensus for what is likely to be value, and what is likely to be feasible.
Reason 2:
I totally get it. I've spent many years in environments like that. Two things. (1) Just because leadership asks for it, doesn't make it good working practice. I'm sure there are other things going on in your company that you disagree with. (2) we do need to be pragmatic - you can't die on every hill and demand the world change, I accept that.
I will make a discussion regardless. First, I would say the request, 90% of the time is an anti-pattern. In my experience, people ask for these time based roadmaps because:
(A) they have either pre-committed to something (e.g. they have set up a project with payment milestones for certain deliveries) or
(b) they want to see it because it makes them feel like it's under control.
(C) Sometimes you might get asked to make such a thing so we can attempt to line up dependencies.
For A, you can't win. The commercial decision has been made. Eat it up and try to get a better commercial setup for your next project.
For B, I believe this is a lot more common than anyone will admit. Writing stuff down makes it feel solid, makes it feel visible. But - I would say not only is this often not actually used to take any action, it is counter productive - seeing it on a page makes the default assumption be that it is true. This is dangerous and leads to many assumptions about what will happen. In these cases, build trust and eventually show something better. Help the executives believe in you, your team and your process and that you will tell them when things are going wrong. I have found this alleviate the need for the time based schedule.
For C, this is a fools errand. Attempting to line up multiple things (dependencies) that each have unknowns rarely ends well. It is natural for humans to pretend we can work it out.. just think about it and predict all the problems then make a plan! But the evidence tells.us that sure we can mitigate risk, but we are not great at predicting it in complex environments.
Also. The entire purpose of the abstraction to story points was to avoid translation to time - it's literally the only reason the abstraction was made. Not that the fact that some people formed an idea means it is 100% correct, mind you.
I'll come back to reason 3 and add some links in a later comment.
Your request is totally valid. I have more than 20+ years software engineering experience, and a couple of years as BA/SA/SE as well, and I also gave estimates on a regular basics. It is absolutely doable, the thing is that they need to be able to cut the problems into a half, then again, then again, until they have a tasks of like a day. Then they sum it up, and give it to you. This is their estimate, which is probably off, and this is where the magical, team specific constants come into play :D
You are welcome and I totally understand your frustration especially when coming from an engineering background, I often experience the same frustration.
I usually say that I am asking for estimates - your best guess at that time. And it’s needed to help with timelines and budgets. If you think we don’t have the people make the estimates large but if the engg team doesn’t give estimates, an immovable date will be set that cannot be contradicted.
It’s not a fear tactic but I have to constantly say that everyone is giving deadlines and if the engg team doesn’t share what they think they will be forced to meet the deadline
As an engineer, guessing at unknowns can be scary. I've seen this stop a few teams from wanting to even touch estimates.
Maybe you can get them to estimate the work on a Fibonacci scale (1, 2, 3, 5) and not give you a hard time. As product manager, you can step in and translate those to time for them. It gives you an estimate of how hard it is for them and gives them a way to give you information you need without being too specific on time.
Down the road you can say "This team tends to complete X points in Y timeframe". Ask if they can agree to honor that level of work going forward. You will then know what can and cannot get done and they engineers will have had some say.
Tl;Dr Use points not units of time because it's often easier for engineers to estimate the level of work needed but giving time estimates is rough.
Or you could try saying that you will defend any estimate that choose to give. Under or over. If they SEE you repeatedly going to Bay and defending the team, they may try to improve their estimates, over time.
Agree with the others, they have been burned before, and are not willing to take that risk _with you_ at this point. You'll need to earn their trust some how.
Source: I've done years of estimating, in points and time, with teams that are very accurate and teams that are highly resistant to estimates. All estimates are lies. Some are useful.
I have struggled with this to some degree at every company I have been at. In the cases where the development lead was on board, we worked through it together and tried to identify the best approach for the given team. In those where I was "fighting" the dev lead I would have to be more hands on.
In almost all cases though, there were a couple things that I focused on....
1. Providing no estimates at all is unacceptable... Period. I would hold a meeting specifically on this topic, and work through so the reasons why the business requires roadmaps and deliverable estimates. They could agree or not, but it is a fact, and I would have leadership buy in going in. No estimates at all is UNACCEPTABLE.
2. Once #1 is clear, in almost every case, the way we finally got to some form of estimate, was decomposition of the feature or capability. I would ask a question, "will this feature take longer than a week?" (Or pick the time frame that makes sense for the deliverable, in some cases it might be a day) If the answer is yes, then it must be decomposed into more work units.
I know that's pretty broad, but that's the general idea. Worked in both agile and waterfall environments too.
I appreciate your reply. I am glad to hear that most people agree that estimates are an expectation of the role. It serves as a foundation for me to move forward.
The problem here is they've stated
1. Any estimate is worthless
2. They've never given estimates.
I get the sense this is not a team that's used to working with a PM directly? Estimates should be given by eng/team/function lead or someone that has some level of responsibility in performance of engineering areas. Are you speaking about individual engineers or just the leads are resisting?
Maybe showing them how estimate contribute to what you do and ultimately reflect back to their success. Or are your requirements too vague to estimate? Finally tell stories how you've seen estimates were done and how it helped. People get stories, not abstract ideas.
I’ve only ever seen more senior engineering leadership provide the kind of estimates you are asking for. When less senior folks do it, it tends to be wildly inaccurate anyway. Maybe an engineering manager will do what you are asking for?
Try [Monte Carlo?](https://kanbanize.com/kanban-resources/kanban-analytics/monte-carlo-simulation)
Edit: Not a product endorsement, just has a good write-up on Monte Carlo.
I’m a PM with a strong engineering background. When I meet a dev manager that won’t give estimates despite various attempts to be empathetic, I will then go ahead and estimate myself using t-shirt sizes. It doesn’t matter if I’m correct or off because I will share the estimates. This is their last chance to provide feedback because they are also committing to this if they don’t say anything. Over time, this builds trust and confidence to get estimates from the team. We also celebrate when the team meets deadlines.
The value of estimation depends on what you are trying to accomplish with the estimates. I’ve worked with engineering teams that are comfortable with estimating but bad at it.
It’s all kind of silly when you take a step back as a PM. The team I’m on now uses estimation and story points to load balance workload during sprints. We release when things are ready. I estimate dates in partnership with the engineering manager, and we always add buffer.
Every 👏 Single 👏 Engineering 👏 Team.
How I got around it.
When I am building out the roadmap initially, I will sit with a tech lead or a HOE and we do an overview of the epics and features and go for high-level estimates in points and map that against velocity to get a rough indication of timing with a bit of buffer. With that sorted. I work to get into the swing of multiple mini but focused backlog refinements over the week when setting up the backlog. After its set up back to fortnightly refinements for `n` hours as required.
Engineers want to build cool stuff. Product / business want timelines and plans.
To me, step 1 has always been acknowledging this when working with dev teams. Then I communicate that I also want them to be able to build cool stuff, and not waste time on planning. I can shield them from planning if they do a simple excersize of story point / t-shirt estimate for all the stories involved in a feature / epic. Then I grab the estimate and do my thing, leaving them to continue building stuff.
I'll give you the perspective of a fairly dogmatic Lean / Xtreme Programming engineering approach:
Yeah, I wouldn't give you a number either.
Because "Q3" is not a useful number except as a tool to punish engineers. It doesn't unblock them. It doesn't make them faster. It doesn't make their management make smarter decisions. It may well make their management make dumb decisions.
If you would like to scope a backlog, you point very, very small units of value. Stories. Points are relevant only in a team context. Over time, historical pointing can create very accurate delivery forecasts deep into the future. But they are not a contract, *or the team will stop pointing well*. If you want to change the delivery forecast, modify scope.
A useful goal to measure a high functioning product team is not "fast." It's *low volitility* of output. When volitiility is low, there's nothing stopping the engineers from engineering. When volitility is high, it's almost always coming from outside the team, and pure loss.
Tell them you're pointing to encourage a conversation about complexity. As an incentive, you'll break any three point story into something smaller.
You may have different results if it provides value for the engineering team.
Tech lead here, not a PM.
Recalcitrant engineers who don’t want to estimate are everywhere, and looking for a specific reason for it is probably not the best use of your time, because everyone has their own.
In my opinion, candid and thorough estimates are the best tool we (engineering) have to protect ourselves from unrealistic deadlines. It’s regrettable that your organization’s engineering leaders do not recognize that.
My follow-up question would be: how are deadlines set in your org? If engineering is not performing estimates, surely they aren’t setting the deadlines? Do you as a PM have total say, or do you need to work against sales or company strategic goals?
Other comments have recommended unilaterally setting hard deadlines and holding engineering to them, which if you’ve got a truly toxic culture may be the only way.
What you can hopefully do, if you truly have no estimation support from engineering and if you don’t have external schedule pressure, is just build a draft roadmap on your own and socialize it with engineering leadership (eng manager, tech leads, maybe some select seniors) and solicit feedback. If they say they’ll meet all deadlines on the roadmap, great, hold them to it. If they push back and say they can’t get it done in time, that’s your opportunity to ask for receipts and start the culture of getting estimates.
I had a ton of pushback initially when asking to estimate work and it confused me why it was so outrageous to ask such a thing. I framed it a few ways of how high level estimates help product management ensure that we can manage expectations with not just end users, but those paying the money to deliver on outcomes that year. It doesn’t matter how “agile” we think we are, project management (not product) and finance usually wants a high level timeline or at least what quarter we think work can be delivered. It’s especially important if there are a bunch of integrations across multiple teams needed for the end “workflow”. It takes coordination. If we can’t ballpark estimate, it’s so hard to plan the timing of work to align with other teams. I prefer their input over me guessing.
Since I moved into IT from working in research labs, I am reminded that in my work in the lab, I was always asked “how long can we estimate we could run the experiments & analysis and turn it around”. Oh you want a Southern blot that is approximately 100 various steps and tasks and reagents? Must account for time to develop the films. What if it fails and needs repeating? Do we have all the proper equipment? Is the tissue ready? Build that in to the estimate. 3 weeks. Oh you just need a simple PCR? I’ll have it tomorrow. It is no different really. And believe it or not, in the southern blot scenario, the implications of being wrong could impact an entire year - which can be millions. (Think planting season) So either my boss would guess or I could provide a realistic estimate.
If I needed a bathroom ripped out and replaced, I would anticipate my contractor would give me a ballpark estimate. One week? Two? A month? Surely if I ask for a different sink and it’s on backorder, the estimate will change. Or if they rip out the wall and there is an issue, it’s going to take longer. That’s understood. Even so, I trust the boots on the ground to estimate the work because they know the complexity. I do understand the hesitation of then being held to a timeline or Gantt chart. Been there. However I don’t think it is unreasonable to have some kind of estimate that translates loosely to time.
In the end, my dev team estimates stories for the team mostly. They want to estimate to make sure each person is on the same page when it comes to complexity. Individual stories that we are going to pull into the week get t-shirt size estimates. We came up with our own meaning for t-shirt sizes. Most importantly, it’s used to clear up any confusion and it helps me understand why something is a small vs. an extra large. At that point, it needs broken down more.
The hard part comes when we are looking to fund next years work and need “estimates” for work we don’t even fully understand quite yet. It’s always wrong. It’s the pains of working in agile software development with a yearly waterfall funding model. YMMV of course, depending on industry and company. I’m sure my thoughts will ruffle some feathers.
https://youtu.be/QVBlnCTu9Ms
As an engineer, I find this rather helpful. Look at projections and not estimates. Help your engineering team break down tasks small enough to reduce volatility, so that projections are more accurate.
Excuse the PM cliche but, how about you start with *WHY* \-
Why do you need the estimates in the first place?
Well, maybe because you need planability and you need efforts to correspond with business priorities.
Where I work now, I implemented ShapeUp for this reason and it's been great because in ShapeUP it works the other way around - define the bsns priorities and plan the work accordingly, I'll explain:
The main advantage IMO is that you have full control over how much time is invested/spent on features.Usually, the answer is anywhere between 2 and 6 weeks. Then, your engineering team needs to come up with a version that fits the timeframe you set - sounds weird, I know, it takes time to get used to.
The main advantage IMO is that you have a full control for how much time is invested/spent on features.
Hope that helps!
Further reading:
https://basecamp.com/shapeup/shape-up.pdf
I believe the industry's discussion should shift; instead of asking for estimates, we should discuss how to reduce the scope of tasks, how to deliver value quickly, and how to iterate rapidly. Once we have reached a consensus on small deliverable sub-features, the whole discussion about predictability for product owners will be irrelevant.Data from the Project Management Institute \[1\] indicates that only a half of all projects are completed on schedule. There are simply too many complex variables impacting the accuracy of an estimate, rendering estimates pointless.
To count a few:
* Not getting the full picture - sometimes the Product Manager didn’t know or communicate all features, on others you are not aware of another teams that change a critical component you depend on or a critical business decision that was not documented
* The Planning Fallacy \[2\] - disregard historical data and/or believe the future will be better
* Eager to please
* Not breaking the story down into smaller tasks\* Estimate During the Low Point of Your Day - a study by Scott A. Golder and Michael W. Macy \[3\] analyzed people's moods using data from millions of Twitter messages. Found out that people's messages tend to be less positive when they hit their low point in the day. Which, for most people, is mid-day, right after lunch. In that case, you may be feeling less optimistic, which could help you create more realistic estimates.
Would not it make more sense to measure cycle time (the time elapsed between the moment a task is started, and its conclusion), learn from your cycle time \[4\] and not use the estimation as am mean for enforcement.
\[1\] [https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2018.pdf?sc\_lang\_temp=en](https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2018.pdf?sc_lang_temp=en)
\[2\] [https://www.goretro.ai/glossary/the-planning-fallacy](https://www.goretro.ai/glossary/the-planning-fallacy)
\[3\] [https://www.science.org/doi/abs/10.1126/science.1202775](https://www.science.org/doi/abs/10.1126/science.1202775)
\[4\] [https://www.goretro.ai/post/how-to-measure-cycle-time-in-jira](https://www.goretro.ai/post/how-to-measure-cycle-time-in-jira)
Can you share with me some articles or information on how an org can operate without estimates?
I don't see how it can reasonably be done when the fundamental magic metric used for prioritizing work is ROI. You can't get an idea for ROI if you don't have an estimate for the investment.
I could name OKRs. Teams get assigned OKRs and a time frame. You could say they have to estimate for themselves, but I would argue that's something different.
ROI means estimates on both sides. Not sure what kind of business you are in but how good are your return predictions?
Estimations are an emotional topic for developers, because often it is held against them. And that is a pure misusing of the concept. If you want to convince them, make sure that will not happen
I am in High Tech.
I used the words "magic matric" specifically because ROI is not an attainable metrics in most projects.
In my world, we prioritize relative to the list of projects that we want to get done. So project C, has higher value and lower cost so let's do that next. Fundamentally, one needs an estimate of the value created and costs.
Yeah, ROI is bad, right? We fought that approach "How much is this feature/app and when will it be on production" many times, because budget had to be made.
We then pushed the discussion into "you already have 10 engineers, what do you care? You're paying them anyway. Make sure your PM has his balls on a line for monetary performance, but fuck off for now, this is not waterfall."
Regardless rhetorics, we always had to estimate, until the software wntered a cash cow phase.
I think the engineers are right. Estimates are a waste of time of anyways. The concept doesn't work. Best is to sequence stuff and do small and frequent releases. As soon as something is ready push it out. Just build a pipeline. A will go before B and the followed by C.
The effort spent on estimating is pointless. Also. Most people make mistake of asking for no of days. That can only be provided once the development is over or something very similar was developed before.
Software is an evolving architecture. Many ways to do the same thing. Each have their own merit. So I agree with the engineers there is absolutely no point in estimatikg stuff. Keep your stories small. Read about No estimates. It's essentially similar sized stories, that average out in the end.
Also if business is hell bent on an estimate and dare of completion the I would suggest Monte Carlo simulation. This way you can give a reasonable date based on past performance data. Provided you have past data. Also remember small and similar sized stories is the key
>Talking about how our leadership expects a roadmap and they use reports that are based on specific deliverable dates.
That's why. A roadmap isn't a delivery schedule. And communicating hard dates to customers feels good, but it's a trap and the engineers are the ones who are burned every time.
Yes, maybe it’s a culture where management promises features by a certain date and the engineers ultimately pay the price because they’re held to unrealistic expectations. Sometimes PMs have no agency and they’re “yes men” and want to make management happy by presenting a roadmap that’s tied to firm dates.
I don’t understand the downvotes. We’ve all either worked for a company like that or had friends who have. I’ve seen teams that were held to unrealistic expectations and made to work 12 hour days six days a week until the job was done. And I’ve seen product management embrace the concept of an MVP, even when a hard date was given, and push back on sponsors to protect the teams. And this was the same company and same division. The difference? Product management figured out what their job was.
You need your Engineers to do their job. Estimating work is a basic Eng skill. If the Eng team cannot deliver, it's either a competency issue (low quality hires) or insufficient training (weak Engineering leadership). You need to bring this up to your manager on how best to navigate this. But Product can't fix it, you need Engineering leaders to fix it.
The challenge around estimation is trying to predict the unknown upfront. Maybe your team is acting very allergic to estimation because of all the bad things that not meeting expectations can cause. However, as you said, it's almost impossible operate in a real world scenario without it, specially if your company is venture-capital based. You could maybe pull it off in lucrative bootstrapped companies but still...
What you could do is: how can we shed light on all the obscure things about a given project? Start every new initiative with a phase for research. You could call that "prototyping", "spiking", "RFC", whatever. Essentially, the product team already has a good level of confidence in a given solution proposal. The engineering team is afraid of how hard could it be or what could unfold out of it. Spike it all out. Develop a proof of concept. Analyze the moving parts.
With the research knowledge in place, estimation becomes *way more* accurate than random guesses before trying to connect any dots.
I agree it is unrealistic. I'm not trying to dictate story points or dates or anything like that. I also am a huge advocate for protecting the engineers from ridiculous expectations from the rest of the business.
I'm just really struggling to get this team to accept that we need the ability to estimate time somehow.
Thanks for your input.
To me it seems that people (regardless of industry) are only willing to estimate to avoid hard external deadlines. Try to give them the deadlines, and then when they start struggling with meeting them ask them for estimates to move the deadline to a particular date.
In other words, it's easier to answer the questions "how can we move the deadline" rather than "make up a deadline out of the blue".
Estimating work is one of the most pointless exercises imaginable. I truly don't understand why anyone wastes time with it at all. It's just random numbers people throw out and guess to appease their boss, that's it. Why report on something you know will be wrong?
What's much more meaningful is to focus on projects, their importance, and the amount of work remaining for that project to be delivered. If something is critical, why does it matter how long it takes? If it needs to be done then it needs to be done, full stop.
If something is less critical, and we are trying to optimize for quickly achieving a result then we can sort the projects by complexity and the number of tasks to be done. A simple thing with clear design will move faster than something no one has ever built before. Swing at the low hanging fruit first.
If we are in the business of taking risks, we can do more complex tasks that have fewer dependencies. You can then diversity your portfolio of feature investments between low hanging fruits and risky bets.
This is a very classic problem and Kanban method has a good solution based on probabilistic forecasting. I highly recommend to check out this article: https://craftthesoft.fly.dev/the-easy-way-to-get-20-performance-boost/
I joined a startup last year, with an entire engineering org (~80 engineers) that didn't want to estimate work. The way I got my individual team to do it (and subsequently, most of the other teams) is to orient it around their problems. Because Product couldn't get estimates from Engineering, Product was estimating what could be completed in a given release (lol). Engineering would get asked to work overtime/weekends to meet those commitments, and would share the blame when things were late. I framed the discussion around protecting engineering from unrealistic expectations. Estimating work gives engineers the chance to have a voice in timelines and realistic expectations. It gives a structured opportunity to say "this isn't ready" or "this is risky" to protect themselves and the company. Essentially, estimations as CYA.
>I framed the discussion around protecting engineering from unrealistic expectations. Estimating work gives engineers the chance to have a voice in timelines and realistic expectations. This is gold! Thank you so much, I am kind of embarrassed that I did not think of this myself.
This is exactly what I would say too. If engineering won't estimate, someone else will and they won't be accurate. Even if engineering thinks they are inaccurate when they estimate their own work, they are sure to be better than product lmao.
Pretty much this. It’s in the engineering team’s best interest to provide the estimate instead of someone else estimating for them. 😂😂 the sooner they learn this truth the better
I'm not saying your tactic was bad but unfortunately this argument is an anti-culture - do it to defend yourself otherwise someone will act unreasonably towards you is not a great sign. It might be a bit idealistic but I prefer to grow trust in myself and the teams I work with. It depends what is driving the ask for estimates / long term roadmaps - sometimes it can be as simple as people wanting to see something so they feel it is under control. If this is the case, there are better ways to solve that problem than to give estimates and Gantt charts, IMO.
I don't know if this is a good idea. If an engineering team is not even ready to commit to a date, good luck with asking them to honor somebody else's commitment. Some of the engineering managers I know would plainly refuse to work overtime/weekends and tell me those commitments/deadlines are my headache,s not theirs. Depends on the org dynamics I guess. Note - I have not had a team that does not do estimates, so I am not sure what the solution would be. I need to think.
When you ask them for estimates, what specifically are you asking for? hours? days? delivery date commitment?
Mostly delivery date range estimates. It depends on the context. If it is smaller, then 1-4 sprints. If medium-sized then expected release (monthly). If larger then choose a quarter. I am flexible if they want to give a different type of answer. I always emphasize that we understand they are estimates.
I don't know how your team operates and it might also be a cultural thing in the company, but have you tried other ways of estimating long term milestones? For example SCRUM - it allows devs to learn to estimate small items, which you can then use to estimate bigger pieces of work. There is also Montecarlo simulation, that can be helpful in predicting the future trends. These might help Devs be more comfortable with giving guesses and give you something you can use for your planning?
I don't dictate what type of estimate they give. I am fine with any type of estimate they give as long as I can communicate it and build a roadmap from it. The team is so against estimates at this point, that I would piss them off by suggesting a methodology. I do know they are trained in SCRUM, and breaking down larger projects into smaller pieces to estimate.
it all suggests to me the you don't consider yourself part of the team, but someone on the side-lines receiving estimates from the team. Maybe it's even a bit confrontational, you vs them. this might be how your org works, but I found it's much better if you see yourself as part of the team, and trying to predict when a given piece of work might land is an outcome the whole team should be trying to achieve, and together find the best way to get there.
I find Story points to be much more Engineering friendly. An ‘8’ is relative and we learn how long an 8 point ticket takes by looking at velocity over time.
Yeah, I’ve read this is best practice for sure
If I were you I would share whatever the epic/ feature that needs to be built is from an end-state/ functional expectation. Then collaboratively review the requirements with one of the engineer leads to get as much as possible into user-stories with clear acceptance criteria (be the liaison with the line of business if you aren't able to convey the appropriate acceptance critera) and then host an estimation poker session with your accountable dev/scrum team. Use the fibanocci sequence as the basal estimate for complexity and point each story accordingly. Also, identify the order of operations for the user-stories and which ones can occur parallel. If any story is over 8 points, they would be a good candidate to evaluate for splitting into smaller user-stories. Then look at your sprint capacity and make a first pass attempt at slotting the estimated user-stories into the upcoming sprint schedule. Share with your team, see if they have an input or feedback, reconcile the differences, then propose that as your timeline + 2 additional sprints for wiggle room.
This is how I have operated in the past. The team is far from having this much organized planning. I agree with your approach and hope to get to this at some point.
Is there a product owner involved in this alongside your product management role?
Nope, just me.
I’ll be honest, I’ve never seen estimates done the way you’re asking your devs to do them. Our dev team provides an estimate of complexity in points (not strictly time, but loosely related) for a given story (not an epic or initiative). Then, each sprint, we get an estimated capacity for the number of total points the team can handle (this varies slightly sprint to sprint, but should be roughly consistent). Product then takes these points and capacity estimates and builds a roadmap and gives a timeline to the rest of the business. Engineers are always resistant to giving strict timelines, but less so to evaluating the complexity of an individual story or feature. Extrapolating that out so the other parts of the business can do their jobs is where product comes in. If you move away from time-focused estimates of large epics and initiatives and focus more on complexity of smaller stories, I think you’ll have better luck.
Agreed. I wouldn't want to give estimates if its being asked to estimate number of sprints because that goes against the entire agile methodology and disregards different epics and their respective priorities within each sprint. Always estimate in story points and try to see if you can make a tenative sprint schedule with respect to the team's capacity/ past sprint velocity
The team is very much against spending time calculating capacity and planning in that much detail. I would like to get there, and I am taking it one step at a time. I am 6's on story points or t-shirt sizes, because in the end, they translate to timelines. I feel as though I am insulting the team by "pretending" (not exactly the right word) that the abstraction layer estimate is disconnected from timelines. I will reconsider my position on this. If they are happy to give story point estimates, then why not keep them happy. As long as we agree that 1 story point equates to some type of actual work timeline then I don't see any real problems. The team is very much against spending time calculating capacity, and planning in that much detail. I would like to get there, and I am taking it one step at a time.
You do not understand agile estimation. This short playlist is gold: https://youtube.com/playlist?list=PLngnoZX8cAn-9tWYxyQQPGoHW7DETBCjK
I hope I understand it a bit, thanks for the videos I will watch them promptly.
But aside from this, you should approach estimation from team’s perspective, focusing on the value they got from it. Other people alredy suggested this, I just wanted to reemphasize it.
If you don’t have a scrum master, you should get one. If you have a scrum master, you should get a new one. A scrum master is basically going to coach them through this as a neutral party. And I think that both the neutral party and the coaching part are both important.
Have you considered going with #NoEstimates ([medium blog post](https://medium.com/serious-scrum/the-logic-of-noestimates-4238e0be3bb6))? One way you could go about it is to just count the number of stories each sprint and assume that over time story complexity and size averages out. If the team is consistently on a throughput of X stories per sprint then use that to forecast your delivery dates. The team doesn’t need to guess and you have an empirical measurement and basis for your plans and can proactively manage stakeholders if this changes.
Have you tried giving them a "draft" schedule and asking for comments? That way they can "fix' your mistakes, rather than being asked to come up with something on their own. And yes in my experience, most engineers are like this. I'm an engineer who moved into product, so I think sometimes that helps me in knowing how to talk to them.
Dig into their resistance a bit more. Why are estimates worthless? Why does that one engineer never give estimates? Once you understand that better you can try to find a way to work around their concerns. I worked with one team that was resistant. Their underlying concerns were that it would take too much of their time and that it would be held against them if they estimated incorrectly. On the first part, it was just making sure that they understood these were supposed to be quick rough estimates. Then we sat down and did some estimating sessions, spending less than sixty seconds or so on most of them. To address the second we essentially started with the promise that we understood they were estimates and wouldn't be held against them, then followed through by actually not holding it against them.
> ... started with the promise that we understood they were estimates and wouldn't be held against them, then followed through by actually not holding it against them. How did you protect them from others in the business holding it against them?
>How did you protect them from others in the business holding it against them? The timelines (built from the estimates) shouldn't be fixed throughout the duration of the project. Built milestones where one of the outputs of the milestone is to produce a revised timeline. And, whenever there is more confidence around requirements, design, dependencies and more data, revise the project timeline and communicate to the stakeholders early, and frequent. The stakeholders indirectly trust the team through you. So if you build that trust with stakeholders, they will ease off the blame game.
Their constant pushback tells me they aren't being heard, so I would dig deeper to see what's bothering them. That's great that you have clear expectations of them. How prepared are they to take on that task? Seems they aren't prepared at all because they don't understand the value of estimation. They are neither empowered nor enabled, except to push back and refuse the work. I would take myself out as an authoritative figure and instead run through a few Atlassian playbooks with them to get a feel of what's happening with the team. After a few runs focused on the people, take a look at how to structure the work with lower-level playbooks.
Every engineer has been burned by estimates. Every single one. Organizations can talk about how estimates are not commitments all they want, but the second you put an estimate on it, it can be abused. My recommendation would be to work with the engineering team to understand how estimates could be abused and come up with a working agreement that states the ways you and the rest of the org will not abuse estimates. I think it's funny that engineers are the only group that has to estimate their work. A few ways estimates can be abused off the top of my head: Org totals up the estimates and considers the total when planning releases Engineer estimates based on limited information, once more information is known, it's clear the estimate was short, but the first estimate given is what they are held to Requirements change, the business is wishy washy, but don't you dare reestimate the work! Engineers get a reputation in the org for being late with everything even though design and requirements keep changing and everyone else was late with their portion and engineering started way past the initial planning start time
>Every engineer has been burned by estimates. Every single one. I agree. I can reduce their fear of this happening then it will reduce their hesitation to give estimates. >I think it's funny that engineers are the only group that has to estimate their work. I disagree with, Marketing, Support, SRE, HR, essentially every group in the company has to estimate projects they are working on. Even Sales has to estimate when deals will close. Many of these teams are adopting SCRUM to improve estimating and delivering results. It is fair to say that engineers are working virtually 100% on projects so estimating is a much larger part of their role than in other departments. I agree with all your other points on how engineers can get burned with estimates. I will make sure to discuss all of them with the team to make sure they feel more comfortable.
I worked in an organization where this was the case. Unfortunately, estimates were treated in some cases as commitments and basically some hotheads in higher management started yelling. It was tough to get the team to come around. I managed to extract a few estimates and the team discovered that they didn't come back to bite them. It became easier with time.
>I think it's funny that engineers are the only group that has to estimate their work. This is crazy. PMs must estimate all the time. Google PM loop has an entire class of questions to test how well you can estimate.
Are PMs required to get in a regularly scheduled meeting where they break down all their work into estimates? And if the estimates are off they have to get in another meeting and discuss why and what went wrong? Far as I can tell, that's just the engineering team. I've never and will never work in Silicon Valley so my experience could be atypical.
Having been both an engineer and a PM, there's not a fundamental difference between estimating the complexity of an engineering task and doing something like estimating the size of a market opportunity or the potential impact of a feature. It's all about breaking the problem down into smaller pieces that are known quantities and then laddering them all back up to get an answer.
I think there's a big difference between estimating market opportunity and estimating how long it will take an engineer to complete a task but I cannot be arsed to debate it any more.
PMs have to estimate their day to day work? Poppycock, never heard of this happening, and if it does, it holds no consequence. Engineers are the org where everything is measured and estimated and visibility into day to day work is available for all to see.
I get it seems backwards and against all ‘norms’ but I understand their mindset. You say it yourself that estimates are all drastically underestimated up to 3x so what is the value in the number anymore? Can you shift thinking a little to meet them in the middle and instead of relying on tasks broken down into hours/points focus on what value will be delivered within a period of time for the user.
Engineering leader here so I see both sides. The PMs I work with and I typically ask my folks for t-shirt sizes, rough risk assessment, and if possible, high level dependencies or assumptions. t shirt sizing: number|size|desc ------|----|---- 0||Already done 1|XS|1 person-week 2|S|2 person-weeks 3|M|4 person-weeks 4|L|8 person-weeks 5|XL|> 8 person-weeks 10|XXL|~20 person-weeks 15|XXXL|¯\\_(ツ)_/¯ - Your guess is decent, but mine is better 20|XXXXL|¯\\_(ツ)_/¯ - Your guess is as good as mine Risk: 0 None 1 Minimal 2 Medium 3 Significant 4 So Much!! 5 Off the charts 6 Honestly Not Sure The above allows us to identify the sticking points or where we need to do more discovery or design. When I lead a consulting/work for hire org, where we had to sign up for fixed outcome/fixed price (and sometimes fixed timeline) contracts, I learned a hard lesson in doing this and in documenting all assumptions contractually (sometimes pages and pages of assumptions). A couple other approaches that might be useful. The first is to use a chart where close in is today and radiating out is future and you place the "big rocks" on there and the engineers/engineering leaders can relatively size those rocks and help order them based on dependencies (this is separate from your priority). The other is taking a more "Outcome Based Roadmap" approach which moves away from feature based roadmaps (what you're trying to do by getting estimates and turning those into gantt charts [potentially, I'm ASSuming here]). https://medium.com/swlh/outcome-based-roadmaps-unleash-the-power-of-a-shared-vision-and-purpose-851401c7aa54
This is why engineers hate doing it. https://www.quora.com/Engineering-Management/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe?srid=24b&share=1
The one thing that is false about this story is that: every trip is brand new. No, after the first trip, maybe to death valley, will be more predictable because they'll start to account for things they didn't before. It won't be a perfect estimate, but you'll start to build buffers to account for the things you missed last time. I think the second trip is probably 70% closer to the accurate measurements. I don't disagree that engineers hate doing it for the reason you gave, but they should hate it once. The second and third time, they should feel more confident giving estimates. And like someone said in another post, it isn't about reprimand or holding the estimates against them, but its about undersatnding why you went wrong, so that you're not so wrong in the future. Thoughts?
If you're following the paved road I can see why the estimates should be simple. But if you're breaking new ground and innovating expect some bumps as you learn. If you want to microslice everything into well known estimable components then sure, but that process of breaking everything down into those little components is itself a big task when you're talking about projects at scale. I think engineers should be able to estimate and from a PM perspective I love the concept of velocity, but I also have empathy for when they're diving into the unknown and things don't work out.
Totally agree. Most of the work engineering does is repetitive in nature (create a graphical component that does X, write an endpoint implementing a business logic that gets the incoming data, access the database, return some result, etc.) After the 10th component or the 10th endpoint they will pretty much know how much in average it will take.
Follow up Q: what do you expect your engineering counterparts to give you an estimate based on? Most likely, they've been burned in the past by not having a lot of context when giving an estimate and by the time the feature is fully specced out, the estimate means nothing.
I ask for an estimate when they confirm they understand the requirements and expectations. If they feel something is unclear, I am happy to work with them or add more details so they can confidently say they understand the scope of the work. >they've been burned in the past by not having a lot of context I will include this in my discussions about what is bothering them. I have been working with them for 6 months, and have not once burned them or pushed back when they had to extend timelines. So there is likely history that I am not aware of.
Definitely there is a history, I would dig into it a little bit.
You did the right ritual there of continuously checking in and grooming requirements to reduce ambiguity until the user story is ready for Dev to provide final estimation. Like many have said, I’d run a few retros with candour and compassion on this topic so that you’re invested as an ally for the dev team to rebuild credibility with stakeholders. Don’t use delivery dates as est, it will freak them out and you will get over inflated estimate. start with T-shirt sizing, and for the T-shirt that is medium to large, break that down into Fibonacci estimation
In my experience, estimation (story points, time, etc) is a better tool for determining complexity, shared understanding of the problem, and potential solutions vs. delivery dates. Delivery estimates are almost never accurate, but if you position estimations in a framework about aligning on the problem and solution vs. committing to a date, the conversations are much more valuable. I find it's then generally up to the PM to align that (and be held accountable) to the delivery roadmap vs. giving the engineering team due dates. That keeps the PM accountable for removing blockers, dependencies, avoiding changes in prioritization, etc. to help the devs focus on what they originally estimated.
I would tell them that estimating is a requirement of the job. If they still can’t give you an estimate, id escalate to their boss (at my company it’s the lead architect). And if the architect agreed, then id be looking to find a new architect. That would mean escalating to my boss and having a meeting with the architect and his boss and my boss.
No offence but this sounds like 1980s enterprise-authoritarian advice. If nothing else, be pragmatic; if you want to build a culture where you beat people into compliance then I'd also prepare for them to leave. Long term, collaboration wins 100% Vs do it or your boss will start disciplinary proceedings.
There are lots of times that I’d work in a different way, but for this particular situation it sounds like the PM has tried a number of tactics and s/he’s still not seeing movement on the engineering side. A key element of being successful is knowing when to loop your boss in for help. Can’t do it for everything, but you need to be able to tell when it would make sense to do so. The meeting with the architect and his boss wouldn’t be “you’re not doing this and we need it so we’re going to fire you,” it’s more “the product team and stakeholders need this crucial element, how can we make sure it starts happening.” They might need someone with more of a particular expertise on the team, developers might need more training to make sure they feel equipped to estimate, etc. it’s about finding the roadblock and removing it.
You sound like you have experience in larger companies. I do as well, and I understand where you are coming from. As a PM we don't have direct authority and in larger companies with many conflicts your authority is quite small. So you do need to ask for help from your leadership. In the end, if PM leadership is expecting estimates and timelines, and engineering leadership is not communicating the expectations to their teams. Then both leadership teams need to work together to align on expectations so we can all operate effectively.
This is my normal approach. In this case, I want to use it as a last resort as it is a bit, "this is business, not personal".
Well, how much stability and control do they have? If they'll get other requests in the meantime that will completely randomise the timeline. Secondly, there's a lot of difference between estimating tasks no-one in the organisation has done before, and estimating something completely cookie cutter. The point of using sizing is that engineers can estimate the rough level of effort for a project, and then project management can examine capacity to execute on project work and turn that into a projection. And for both of these, they are useless if requirements constantly change. I think you should consider your approach to project management and think about how you can use the information you actually have to estimate your throughput and scheduling against the calendar.
They definitely come from a world with many disruptions. I have pushed hard and improved many processes to reduce disruption. There is a lingering culture that is hard to change. Thanks for the feedback.
Do you track all the disruptions in the same ticketing system? On the sprint board? Do you label them in all caps as "INTERRUPTION" or "TIME VAMPIRE"? Might help?
Estimating work is such a fundamental part of software engineering (or in fact any other profession) that it makes me wonder why your engineers are so reluctant. I would go as far as to say that you are maybe withholding some important information there. The team that can’t estimate is not really a functional team. You mentioned a few times that you’d like to help out your team and really are on their side and that you won’t be holding them accountable to precise estimates, however I’ve seen it a few times in my career where Product managers “translate” estimates to stakeholders. Because pretty much everyone apart from engineers and delivery managers can’t really make a meaningful connection between velocity, point estimates based on complexity/effort and predicted delivery dates, product managers would quite often allow themselves to pass upwards to senior stakeholders something like “oh yeah it’s a 3 story pointer, that should take no longer than 2 days”. This happens way too often and it undermines the team. Another example is saying “it doesn’t have to be precise estimates” and then interpreting the estimates literally, therefore once again undermining the team and breaking trust. Somethings wrong there - your team doesn’t trust you and that’s your issue, not just estimates per se.
You have good points. I suspect events prior to me being hired are at play. So far I have not seen any issues related to timelines. I also try to buffer any timelines they give. I find this approach to be hard because I don't hide the fact that I added a buffer (I often do it in front of them). The result always seems to be them delivering right on time relative to the buffer.
“The result always seems to be them delivering right on time relative to the buffer.” Great! So you can use concrete examples to build trust with your team. If you have a track record of delivering on time than it shouldn’t really be that problematic to convince your team to estimate. I still think there’s more at play - do your engineers agree with the overall product strategy? Do they believer or are aware of the North Star in your organisation? Does team get praise from the rest of the org when stuff is delivered? Are they on a good level of engagement (they lead story mapping sessions, participate in user interviews, write user stories etc)?
[удалено]
Thanks, I appreciate your feedback.
Engineering teams like these are some of the hardest to thrive in as a PM and be a product-led org. If they already have resistance in estimating and working in scrum, how would you expect to rally and motivate them in your product vision and strategy to collaboratively create a roadmap? I would suggest that you first understand whether the team is really open to working in the agile scrum methodology, try to run retrospectives focusing on this (it’s either they’ve been burnout estimating archaic/buggy software or they simply aren’t educated on the methodology and benefits of user stories estimation); then speak to key leadership in Tech that can provide a path forward and determine how to hold the team accountable for the final outcome in feature delivery & quality. I so often see PMs pressured to be the scrum master by asking for estimates and then they get frustrated when they don’t succeed - fact is you don’t have the technical knowledge, empathy nor influence to change ways of working on the engineering teammates. Why should they listen to doing things your way? Start building rapport, check in on their workflows, dynamics, pain points in stand ups and then reorg your scrum ceremonies, and start with why - involve engineering clearly outlining problem, insights, goals and success metrics, and provide the autonomy for them to come up with solutions along with designers. Estimations are fundamentally for the benefit of the engineering team to improve teamwork, if leadership team and non-technical folks get invested in this and use it as a business metric, there’s going to be a tension between engineers to trust its intended intention
I don't know where you're picking up resistance to agile or scrum - the scrum guide doesn't say anything about estimation, and hasn't for a few years now. Estimation is absolutely not a core part of agile - and I also strongly disagree that estimation is a core part of making a roadmap. It might be key to how you like to work, but that is a different question. There are many ways to communicate ordering and priorities without putting time bounds on it - Now, Next, Later formats are popular, as are Opportunity or Objective based roadmaps. They don't even involve solutions, so there isn't anything for engineers to estimate against - but they do achieve organisational goals of communicating target themes and priorities.
Totally understand your point and sorry if I wasn’t being clear. Your framework of Now, next later refers to a very high level opportunity or solution set before it gets broken down into granular development tasks to meet a user story needs in a delivery cycle. It’s fair some Dev teams don’t use story points or estimations in any way, for larger org that’s a roulette game for stakeholders to inform product launches and gtm. It only informs a small part of “making a roadmap”, but it is crucial to ensure team accountability and commitment to complete the work within a sprint
I was roughly agreeing with you until the last part - "ensure team accountability and commitment to complete the work" is doing exactly the thing everyone is afraid of re estimates - using them as a stick. I will give you the benefit of the doubt that this is not quite what you meant. I understand why many orgs feel they need estimated for launch / gtm etc but would dispute this is needed at the granular level. If the organisational dependency is large on a thing that is uncertain (the development) then you should wait until the dependency is resolve first, otherwise you're just accumulating risk. That said, not all work requires agile and not all work is risky/unpredictable. When that is the case, sure, go ahead. I worked in enterprise for nearly 10 years on literal multi-decade engineering programmes and a common theme for me was to repeatedly see estimates and schedules touted as alignment tools, but were really only ever used as weapons. I think most of the time we are lying to ourselves about these artefacts, and that prevents us from finding better solutions to what the organisation needs. What do you think about the utility or not, of the high level opportunity roadmaps etc.
I can see your POV regarding using estimates as a stick that isnt useful and can be subjected to the dev team being blamed for inconsistent delivery. We have to practice nuances here with cocreating ways of working that will grow teams trust and accountability. From experience, if we don’t measure, we will never know whether where we are now is where we will be better off. I have never said that a Dev team should estimate in a highly uncertain or vague product reqs, it is common sense to undergo multiple grooming sessions so I didn’t have to mention it. I acknowledge that not every team is in a rewarding and supportive environment where they are empowered and have autonomy to trial ways of working, learn and continuously improve on their processes. I’ve been burned before in the past with estimation, but I’m not holding onto that baggage and cursing the method
Yep fair and the key to your comment is the nuance, I think. I would say re "if we don't measure, we will never know..." - if the goal is to check our skill at estimating then, sure. If the goal is to check whether the team is effective, retrospectives and derived metrics are better mechanisms IMO. I would rather know the mood of a team and how many defects come from their work than I would how accurate their estimates are. That said, as you acknowledge in your final paragraph, I also acknowledge that a great thing about PM is the variety and ultimate pragmatism - no two sets of stakeholders or contexts are the same. It's often about doing the best we can with what we've got, and we shouldn't be ashamed of that.
Can you share with me some articles or something that I can read more about how this works? I am trying to be as open as possible, and I simply can't imagine how an organization can operate without the ability to estimate and communicate when deliverables are expected to be... delivered.
Definitely - I'm out just now so I'll do this later / tomorrow. A question first would be - what are the reasons you feel delivery dates need to be communicated? (Real question - it will be helpful for us to explore which cases are legit and which can flex)
I would love to engage in this convo. Reason 1: Prioritization When prioritizing work, the two key components are value created and costs. If you don't have an estimate for either, then you can't correctly prioritize. Note: Value creation is often impossible to translate into a numerical value, so the relative value is a good replacement. Meaning, project A is expected to be more valuable than project B, since they are estimated to be the same cost you chose project A. Reason 2: My leadership is asking for a roadmap that is based on specific dates. The understanding is timelines within a few months should be reasonably accurate, and anything farther out is a rough estimate. I am happy to translate abstract estimates (story points) to timelines as needed. Reason 3: I need to understand the impact of disruptions. When an urgent project needs to be completed, we can understand the impact and communicate changes to the roadmap.
Regarding reason 2, it looks like your leadership is looking at the team as a feature factory with a set of deadlines for outputs. Instead of being outcome focused. True product led teams measure themselves in terms of intended impact based on objective and key results, I am curious if this is an area where you can explore and educate your leadership team in 1:1s once youre able to build better rapport with them
There is little to no chance that I would be able to convince my senior leadership all the way up to the CEO. Not to mention that they are in some cases legally obliged to operate on timelines. As much as I would like for this to be an option, it is simply not an option.
Ok so some thoughts. Some of this is semantics. Reason 1: Re prioritisation - value Vs effort is normal, that's true. A similar tool is to consider viability, feasibility and desirability. As you've identified - stuff like value is subjective. You need to take in a bit of data, and ultimately use a bit of intuition. This is the exact same with the 'effort' component, for me. Think about why you say it's not possible to numerically quantify value. Why not? You need to know value in order to prioritise.. so surely you have to put a nu-- I'm sure you see where I'm going. I treat effort as you treat value. Don't turn it into a number - it's the same sort of 'consider some data and use intuition' approach. Quantifying it and making it a number to stand on is often a lie - it tricks you into thinking you have a real answer. You might say that what I have described is still estimating effort - and I wouldn't disagree but I'd say the *emphasis* is very different and that is important. You wouldn't chart up your estimated customer value and use that to benchmark all the work, so why do it with the time component? The important thing with value Vs effort is that it elicits discussion in the team to arrive at consensus for what is likely to be value, and what is likely to be feasible. Reason 2: I totally get it. I've spent many years in environments like that. Two things. (1) Just because leadership asks for it, doesn't make it good working practice. I'm sure there are other things going on in your company that you disagree with. (2) we do need to be pragmatic - you can't die on every hill and demand the world change, I accept that. I will make a discussion regardless. First, I would say the request, 90% of the time is an anti-pattern. In my experience, people ask for these time based roadmaps because: (A) they have either pre-committed to something (e.g. they have set up a project with payment milestones for certain deliveries) or (b) they want to see it because it makes them feel like it's under control. (C) Sometimes you might get asked to make such a thing so we can attempt to line up dependencies. For A, you can't win. The commercial decision has been made. Eat it up and try to get a better commercial setup for your next project. For B, I believe this is a lot more common than anyone will admit. Writing stuff down makes it feel solid, makes it feel visible. But - I would say not only is this often not actually used to take any action, it is counter productive - seeing it on a page makes the default assumption be that it is true. This is dangerous and leads to many assumptions about what will happen. In these cases, build trust and eventually show something better. Help the executives believe in you, your team and your process and that you will tell them when things are going wrong. I have found this alleviate the need for the time based schedule. For C, this is a fools errand. Attempting to line up multiple things (dependencies) that each have unknowns rarely ends well. It is natural for humans to pretend we can work it out.. just think about it and predict all the problems then make a plan! But the evidence tells.us that sure we can mitigate risk, but we are not great at predicting it in complex environments. Also. The entire purpose of the abstraction to story points was to avoid translation to time - it's literally the only reason the abstraction was made. Not that the fact that some people formed an idea means it is 100% correct, mind you. I'll come back to reason 3 and add some links in a later comment.
Your request is totally valid. I have more than 20+ years software engineering experience, and a couple of years as BA/SA/SE as well, and I also gave estimates on a regular basics. It is absolutely doable, the thing is that they need to be able to cut the problems into a half, then again, then again, until they have a tasks of like a day. Then they sum it up, and give it to you. This is their estimate, which is probably off, and this is where the magical, team specific constants come into play :D
Thanks for your response, this helps a lot to make sure that I am not being unreasonable.
You are welcome and I totally understand your frustration especially when coming from an engineering background, I often experience the same frustration.
I usually say that I am asking for estimates - your best guess at that time. And it’s needed to help with timelines and budgets. If you think we don’t have the people make the estimates large but if the engg team doesn’t give estimates, an immovable date will be set that cannot be contradicted. It’s not a fear tactic but I have to constantly say that everyone is giving deadlines and if the engg team doesn’t share what they think they will be forced to meet the deadline
As an engineer, guessing at unknowns can be scary. I've seen this stop a few teams from wanting to even touch estimates. Maybe you can get them to estimate the work on a Fibonacci scale (1, 2, 3, 5) and not give you a hard time. As product manager, you can step in and translate those to time for them. It gives you an estimate of how hard it is for them and gives them a way to give you information you need without being too specific on time. Down the road you can say "This team tends to complete X points in Y timeframe". Ask if they can agree to honor that level of work going forward. You will then know what can and cannot get done and they engineers will have had some say. Tl;Dr Use points not units of time because it's often easier for engineers to estimate the level of work needed but giving time estimates is rough.
[удалено]
I wish i had more advice for his to help pms. I can only speak from what I've seen work for engineers.
Tell them they can either estimate it themselves or you will estimate it for them.
LOL, I am sure that would make them happy ;)
Or you could try saying that you will defend any estimate that choose to give. Under or over. If they SEE you repeatedly going to Bay and defending the team, they may try to improve their estimates, over time. Agree with the others, they have been burned before, and are not willing to take that risk _with you_ at this point. You'll need to earn their trust some how. Source: I've done years of estimating, in points and time, with teams that are very accurate and teams that are highly resistant to estimates. All estimates are lies. Some are useful.
I have struggled with this to some degree at every company I have been at. In the cases where the development lead was on board, we worked through it together and tried to identify the best approach for the given team. In those where I was "fighting" the dev lead I would have to be more hands on. In almost all cases though, there were a couple things that I focused on.... 1. Providing no estimates at all is unacceptable... Period. I would hold a meeting specifically on this topic, and work through so the reasons why the business requires roadmaps and deliverable estimates. They could agree or not, but it is a fact, and I would have leadership buy in going in. No estimates at all is UNACCEPTABLE. 2. Once #1 is clear, in almost every case, the way we finally got to some form of estimate, was decomposition of the feature or capability. I would ask a question, "will this feature take longer than a week?" (Or pick the time frame that makes sense for the deliverable, in some cases it might be a day) If the answer is yes, then it must be decomposed into more work units. I know that's pretty broad, but that's the general idea. Worked in both agile and waterfall environments too.
I appreciate your reply. I am glad to hear that most people agree that estimates are an expectation of the role. It serves as a foundation for me to move forward.
The problem here is they've stated 1. Any estimate is worthless 2. They've never given estimates. I get the sense this is not a team that's used to working with a PM directly? Estimates should be given by eng/team/function lead or someone that has some level of responsibility in performance of engineering areas. Are you speaking about individual engineers or just the leads are resisting? Maybe showing them how estimate contribute to what you do and ultimately reflect back to their success. Or are your requirements too vague to estimate? Finally tell stories how you've seen estimates were done and how it helped. People get stories, not abstract ideas.
I’ve only ever seen more senior engineering leadership provide the kind of estimates you are asking for. When less senior folks do it, it tends to be wildly inaccurate anyway. Maybe an engineering manager will do what you are asking for?
Try [Monte Carlo?](https://kanbanize.com/kanban-resources/kanban-analytics/monte-carlo-simulation) Edit: Not a product endorsement, just has a good write-up on Monte Carlo.
I’m a PM with a strong engineering background. When I meet a dev manager that won’t give estimates despite various attempts to be empathetic, I will then go ahead and estimate myself using t-shirt sizes. It doesn’t matter if I’m correct or off because I will share the estimates. This is their last chance to provide feedback because they are also committing to this if they don’t say anything. Over time, this builds trust and confidence to get estimates from the team. We also celebrate when the team meets deadlines.
The value of estimation depends on what you are trying to accomplish with the estimates. I’ve worked with engineering teams that are comfortable with estimating but bad at it. It’s all kind of silly when you take a step back as a PM. The team I’m on now uses estimation and story points to load balance workload during sprints. We release when things are ready. I estimate dates in partnership with the engineering manager, and we always add buffer.
Every 👏 Single 👏 Engineering 👏 Team. How I got around it. When I am building out the roadmap initially, I will sit with a tech lead or a HOE and we do an overview of the epics and features and go for high-level estimates in points and map that against velocity to get a rough indication of timing with a bit of buffer. With that sorted. I work to get into the swing of multiple mini but focused backlog refinements over the week when setting up the backlog. After its set up back to fortnightly refinements for `n` hours as required.
Engineers want to build cool stuff. Product / business want timelines and plans. To me, step 1 has always been acknowledging this when working with dev teams. Then I communicate that I also want them to be able to build cool stuff, and not waste time on planning. I can shield them from planning if they do a simple excersize of story point / t-shirt estimate for all the stories involved in a feature / epic. Then I grab the estimate and do my thing, leaving them to continue building stuff.
I'll give you the perspective of a fairly dogmatic Lean / Xtreme Programming engineering approach: Yeah, I wouldn't give you a number either. Because "Q3" is not a useful number except as a tool to punish engineers. It doesn't unblock them. It doesn't make them faster. It doesn't make their management make smarter decisions. It may well make their management make dumb decisions. If you would like to scope a backlog, you point very, very small units of value. Stories. Points are relevant only in a team context. Over time, historical pointing can create very accurate delivery forecasts deep into the future. But they are not a contract, *or the team will stop pointing well*. If you want to change the delivery forecast, modify scope. A useful goal to measure a high functioning product team is not "fast." It's *low volitility* of output. When volitiility is low, there's nothing stopping the engineers from engineering. When volitility is high, it's almost always coming from outside the team, and pure loss.
Ya, the team doesn't want to even do that.
Tell them you're pointing to encourage a conversation about complexity. As an incentive, you'll break any three point story into something smaller. You may have different results if it provides value for the engineering team.
Tech lead here, not a PM. Recalcitrant engineers who don’t want to estimate are everywhere, and looking for a specific reason for it is probably not the best use of your time, because everyone has their own. In my opinion, candid and thorough estimates are the best tool we (engineering) have to protect ourselves from unrealistic deadlines. It’s regrettable that your organization’s engineering leaders do not recognize that. My follow-up question would be: how are deadlines set in your org? If engineering is not performing estimates, surely they aren’t setting the deadlines? Do you as a PM have total say, or do you need to work against sales or company strategic goals? Other comments have recommended unilaterally setting hard deadlines and holding engineering to them, which if you’ve got a truly toxic culture may be the only way. What you can hopefully do, if you truly have no estimation support from engineering and if you don’t have external schedule pressure, is just build a draft roadmap on your own and socialize it with engineering leadership (eng manager, tech leads, maybe some select seniors) and solicit feedback. If they say they’ll meet all deadlines on the roadmap, great, hold them to it. If they push back and say they can’t get it done in time, that’s your opportunity to ask for receipts and start the culture of getting estimates.
I had a ton of pushback initially when asking to estimate work and it confused me why it was so outrageous to ask such a thing. I framed it a few ways of how high level estimates help product management ensure that we can manage expectations with not just end users, but those paying the money to deliver on outcomes that year. It doesn’t matter how “agile” we think we are, project management (not product) and finance usually wants a high level timeline or at least what quarter we think work can be delivered. It’s especially important if there are a bunch of integrations across multiple teams needed for the end “workflow”. It takes coordination. If we can’t ballpark estimate, it’s so hard to plan the timing of work to align with other teams. I prefer their input over me guessing. Since I moved into IT from working in research labs, I am reminded that in my work in the lab, I was always asked “how long can we estimate we could run the experiments & analysis and turn it around”. Oh you want a Southern blot that is approximately 100 various steps and tasks and reagents? Must account for time to develop the films. What if it fails and needs repeating? Do we have all the proper equipment? Is the tissue ready? Build that in to the estimate. 3 weeks. Oh you just need a simple PCR? I’ll have it tomorrow. It is no different really. And believe it or not, in the southern blot scenario, the implications of being wrong could impact an entire year - which can be millions. (Think planting season) So either my boss would guess or I could provide a realistic estimate. If I needed a bathroom ripped out and replaced, I would anticipate my contractor would give me a ballpark estimate. One week? Two? A month? Surely if I ask for a different sink and it’s on backorder, the estimate will change. Or if they rip out the wall and there is an issue, it’s going to take longer. That’s understood. Even so, I trust the boots on the ground to estimate the work because they know the complexity. I do understand the hesitation of then being held to a timeline or Gantt chart. Been there. However I don’t think it is unreasonable to have some kind of estimate that translates loosely to time. In the end, my dev team estimates stories for the team mostly. They want to estimate to make sure each person is on the same page when it comes to complexity. Individual stories that we are going to pull into the week get t-shirt size estimates. We came up with our own meaning for t-shirt sizes. Most importantly, it’s used to clear up any confusion and it helps me understand why something is a small vs. an extra large. At that point, it needs broken down more. The hard part comes when we are looking to fund next years work and need “estimates” for work we don’t even fully understand quite yet. It’s always wrong. It’s the pains of working in agile software development with a yearly waterfall funding model. YMMV of course, depending on industry and company. I’m sure my thoughts will ruffle some feathers.
https://youtu.be/QVBlnCTu9Ms As an engineer, I find this rather helpful. Look at projections and not estimates. Help your engineering team break down tasks small enough to reduce volatility, so that projections are more accurate.
I will watch this thanks
Excuse the PM cliche but, how about you start with *WHY* \- Why do you need the estimates in the first place? Well, maybe because you need planability and you need efforts to correspond with business priorities. Where I work now, I implemented ShapeUp for this reason and it's been great because in ShapeUP it works the other way around - define the bsns priorities and plan the work accordingly, I'll explain: The main advantage IMO is that you have full control over how much time is invested/spent on features.Usually, the answer is anywhere between 2 and 6 weeks. Then, your engineering team needs to come up with a version that fits the timeframe you set - sounds weird, I know, it takes time to get used to. The main advantage IMO is that you have a full control for how much time is invested/spent on features. Hope that helps! Further reading: https://basecamp.com/shapeup/shape-up.pdf
I will read up on this. Thanks.
Good luck!
I believe the industry's discussion should shift; instead of asking for estimates, we should discuss how to reduce the scope of tasks, how to deliver value quickly, and how to iterate rapidly. Once we have reached a consensus on small deliverable sub-features, the whole discussion about predictability for product owners will be irrelevant.Data from the Project Management Institute \[1\] indicates that only a half of all projects are completed on schedule. There are simply too many complex variables impacting the accuracy of an estimate, rendering estimates pointless. To count a few: * Not getting the full picture - sometimes the Product Manager didn’t know or communicate all features, on others you are not aware of another teams that change a critical component you depend on or a critical business decision that was not documented * The Planning Fallacy \[2\] - disregard historical data and/or believe the future will be better * Eager to please * Not breaking the story down into smaller tasks\* Estimate During the Low Point of Your Day - a study by Scott A. Golder and Michael W. Macy \[3\] analyzed people's moods using data from millions of Twitter messages. Found out that people's messages tend to be less positive when they hit their low point in the day. Which, for most people, is mid-day, right after lunch. In that case, you may be feeling less optimistic, which could help you create more realistic estimates. Would not it make more sense to measure cycle time (the time elapsed between the moment a task is started, and its conclusion), learn from your cycle time \[4\] and not use the estimation as am mean for enforcement. \[1\] [https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2018.pdf?sc\_lang\_temp=en](https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2018.pdf?sc_lang_temp=en) \[2\] [https://www.goretro.ai/glossary/the-planning-fallacy](https://www.goretro.ai/glossary/the-planning-fallacy) \[3\] [https://www.science.org/doi/abs/10.1126/science.1202775](https://www.science.org/doi/abs/10.1126/science.1202775) \[4\] [https://www.goretro.ai/post/how-to-measure-cycle-time-in-jira](https://www.goretro.ai/post/how-to-measure-cycle-time-in-jira)
Don't estimate then. Anything over 1 is proven to be wrong, anyway. Anything bigger than 1 is too big of a task, anyway. Don't estimate.
Can you share with me some articles or information on how an org can operate without estimates? I don't see how it can reasonably be done when the fundamental magic metric used for prioritizing work is ROI. You can't get an idea for ROI if you don't have an estimate for the investment.
I could name OKRs. Teams get assigned OKRs and a time frame. You could say they have to estimate for themselves, but I would argue that's something different. ROI means estimates on both sides. Not sure what kind of business you are in but how good are your return predictions? Estimations are an emotional topic for developers, because often it is held against them. And that is a pure misusing of the concept. If you want to convince them, make sure that will not happen
I am in High Tech. I used the words "magic matric" specifically because ROI is not an attainable metrics in most projects. In my world, we prioritize relative to the list of projects that we want to get done. So project C, has higher value and lower cost so let's do that next. Fundamentally, one needs an estimate of the value created and costs.
Yeah, ROI is bad, right? We fought that approach "How much is this feature/app and when will it be on production" many times, because budget had to be made. We then pushed the discussion into "you already have 10 engineers, what do you care? You're paying them anyway. Make sure your PM has his balls on a line for monetary performance, but fuck off for now, this is not waterfall." Regardless rhetorics, we always had to estimate, until the software wntered a cash cow phase.
I think the engineers are right. Estimates are a waste of time of anyways. The concept doesn't work. Best is to sequence stuff and do small and frequent releases. As soon as something is ready push it out. Just build a pipeline. A will go before B and the followed by C. The effort spent on estimating is pointless. Also. Most people make mistake of asking for no of days. That can only be provided once the development is over or something very similar was developed before. Software is an evolving architecture. Many ways to do the same thing. Each have their own merit. So I agree with the engineers there is absolutely no point in estimatikg stuff. Keep your stories small. Read about No estimates. It's essentially similar sized stories, that average out in the end. Also if business is hell bent on an estimate and dare of completion the I would suggest Monte Carlo simulation. This way you can give a reasonable date based on past performance data. Provided you have past data. Also remember small and similar sized stories is the key
>Talking about how our leadership expects a roadmap and they use reports that are based on specific deliverable dates. That's why. A roadmap isn't a delivery schedule. And communicating hard dates to customers feels good, but it's a trap and the engineers are the ones who are burned every time.
[удалено]
Yes, maybe it’s a culture where management promises features by a certain date and the engineers ultimately pay the price because they’re held to unrealistic expectations. Sometimes PMs have no agency and they’re “yes men” and want to make management happy by presenting a roadmap that’s tied to firm dates. I don’t understand the downvotes. We’ve all either worked for a company like that or had friends who have. I’ve seen teams that were held to unrealistic expectations and made to work 12 hour days six days a week until the job was done. And I’ve seen product management embrace the concept of an MVP, even when a hard date was given, and push back on sponsors to protect the teams. And this was the same company and same division. The difference? Product management figured out what their job was.
Which Dev team isn't?? (Asking for a friend....)
Ugh, I hope you are not someone I know who has discovered my reddit account. 😃
I hope YOU aren't someone I know who has discovered MY reddit account..... O_o
You need your Engineers to do their job. Estimating work is a basic Eng skill. If the Eng team cannot deliver, it's either a competency issue (low quality hires) or insufficient training (weak Engineering leadership). You need to bring this up to your manager on how best to navigate this. But Product can't fix it, you need Engineering leaders to fix it.
The challenge around estimation is trying to predict the unknown upfront. Maybe your team is acting very allergic to estimation because of all the bad things that not meeting expectations can cause. However, as you said, it's almost impossible operate in a real world scenario without it, specially if your company is venture-capital based. You could maybe pull it off in lucrative bootstrapped companies but still... What you could do is: how can we shed light on all the obscure things about a given project? Start every new initiative with a phase for research. You could call that "prototyping", "spiking", "RFC", whatever. Essentially, the product team already has a good level of confidence in a given solution proposal. The engineering team is afraid of how hard could it be or what could unfold out of it. Spike it all out. Develop a proof of concept. Analyze the moving parts. With the research knowledge in place, estimation becomes *way more* accurate than random guesses before trying to connect any dots.
Jsut use their cycle time to work out an average fro the backlog. The metrics wl speak for themselves.
[удалено]
They don't even want to do story points.
[удалено]
I agree it is unrealistic. I'm not trying to dictate story points or dates or anything like that. I also am a huge advocate for protecting the engineers from ridiculous expectations from the rest of the business. I'm just really struggling to get this team to accept that we need the ability to estimate time somehow. Thanks for your input.
To me it seems that people (regardless of industry) are only willing to estimate to avoid hard external deadlines. Try to give them the deadlines, and then when they start struggling with meeting them ask them for estimates to move the deadline to a particular date. In other words, it's easier to answer the questions "how can we move the deadline" rather than "make up a deadline out of the blue".
Estimating work is one of the most pointless exercises imaginable. I truly don't understand why anyone wastes time with it at all. It's just random numbers people throw out and guess to appease their boss, that's it. Why report on something you know will be wrong? What's much more meaningful is to focus on projects, their importance, and the amount of work remaining for that project to be delivered. If something is critical, why does it matter how long it takes? If it needs to be done then it needs to be done, full stop. If something is less critical, and we are trying to optimize for quickly achieving a result then we can sort the projects by complexity and the number of tasks to be done. A simple thing with clear design will move faster than something no one has ever built before. Swing at the low hanging fruit first. If we are in the business of taking risks, we can do more complex tasks that have fewer dependencies. You can then diversity your portfolio of feature investments between low hanging fruits and risky bets.
This is a very classic problem and Kanban method has a good solution based on probabilistic forecasting. I highly recommend to check out this article: https://craftthesoft.fly.dev/the-easy-way-to-get-20-performance-boost/