I have to very strongly disagree on cutting features to maintain the deadline.
We're service providers - to stakeholders first, downstream customers second. Our job is to fulfill the business dream. Discussions about non-mandatory aspects are fine - and I would encourage everyone to question the why and what that's being asked of a development team, but by the time a ticket is considered for estimation, these discussions should already have been had. What ends up anywhere near the sprint is a promise to deliver. Setting a hard deadline is a good means of giving stability to the business expectation, but features should not be cut to meet that deadline - unless that is roadmapped precisely. Delaying the bells and whistles for a later product iteration is good, but estimation is not when this should happen.
Instead - and this is where many teams use pre-refinement and story point caps - tickets need to be refined to a workable state early-on. Call it a 100 if you think this isn't a shippable iteration within a certain timeframe. Tell business to resize the iteration - and help them sort through the bells and whistles, providing product value in a staircase.
I see your point. The thing with chopping things off is that software projects tend to always add more work to the already established time.
With this "chop it off" mindset, what we want instead is to stop adding unnecessary BS to the scope and keep removing unnecessary BS that might leaked when estimating.
I agree that work to do have to be well defined but barely happens in many teams.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have to very strongly disagree on cutting features to maintain the deadline.
We're service providers - to stakeholders first, downstream customers second. Our job is to fulfill the business dream. Discussions about non-mandatory aspects are fine - and I would encourage everyone to question the why and what that's being asked of a development team, but by the time a ticket is considered for estimation, these discussions should already have been had. What ends up anywhere near the sprint is a promise to deliver. Setting a hard deadline is a good means of giving stability to the business expectation, but features should not be cut to meet that deadline - unless that is roadmapped precisely. Delaying the bells and whistles for a later product iteration is good, but estimation is not when this should happen.
Instead - and this is where many teams use pre-refinement and story point caps - tickets need to be refined to a workable state early-on. Call it a 100 if you think this isn't a shippable iteration within a certain timeframe. Tell business to resize the iteration - and help them sort through the bells and whistles, providing product value in a staircase.
I see your point. The thing with chopping things off is that software projects tend to always add more work to the already established time.
With this "chop it off" mindset, what we want instead is to stop adding unnecessary BS to the scope and keep removing unnecessary BS that might leaked when estimating.
I agree that work to do have to be well defined but barely happens in many teams.