47 ms·

I feel like my team lead has forgotten what iterative means, and expects much shorter turnout times in recent months for things that will absolutely not fit int

I feel like my team lead has forgotten what iterative means, and expects much shorter turnout times in recent months for things that will absolutely not fit into a 2 week sprint. Since he kept going on about tickets that were getting stale due to last-minute unrelated scope expansions and me not being able to reprioritize new commitments on old tickets, I've just started being more strict. No, this ticket intended to literally just fix a typo is not also going to fix this unrelated bug qa discovered while testing.

MrGilbert 4y ago
> No, this ticket intended to literally just fix a typo is not also going to fix this unrelated bug qa discovered while testing. That's basically how it is supposed to work. If you need something to get fixed, create an item/bug for it and let it get prioritized.
wildrhythms 4y ago
I think this is a top-down issue caused by people in charge who fundamentally do not understand development lifecycles. When the requirements change at all I have to completely reassess the timeline.
everforward 4y ago
I've found success in cutting tasks up in things that will fit in a sprint. If I have to write a feature, I commonly split it into a few tickets: - Write the code - Test the code - Documentation changes - Deploy the code If it's a big enough change (or a new app), I might create a few sets of those tickets. E.g. one "write/test/document/deploy" set for the database schema to do Y, another one for the business logic to do Y, another for the HTTP endpoints for Y, etc. The tickets are specific to the implementation, not to the feature, so they can't be expanded. New work can only come through new tickets, which get prioritized. Manager is happy because tickets get cleared. I'm happy because I can fight scope creep by pointing to my sprint and asking which tickets they want to bump for their new scope creep. Tickets like "implement X feature" with a 2 week estimate are a landmine for engineers because it's broad enough for the scope to expand infinitely, and it starts to look like nothing is getting done to management.
- brailsafe 4y ago
  This is similar to what I've been thinking, but on the frontend. Tests/Design changes/Core JS for x. Seems like the only way.

MrGilbert 4y ago

> No, this ticket intended to literally just fix a typo is not also going to fix this unrelated bug qa discovered while testing. That's basically how it is supposed to work. If you need something to get fixed, create an item/bug for it and let it get prioritized.

wildrhythms 4y ago

I think this is a top-down issue caused by people in charge who fundamentally do not understand development lifecycles. When the requirements change at all I have to completely reassess the timeline.

everforward 4y ago

I've found success in cutting tasks up in things that will fit in a sprint. If I have to write a feature, I commonly split it into a few tickets: - Write the code - Test the code - Documentation changes - Deploy the code If it's a big enough change (or a new app), I might create a few sets of those tickets. E.g. one "write/test/document/deploy" set for the database schema to do Y, another one for the business logic to do Y, another for the HTTP endpoints for Y, etc. The tickets are specific to the implementation, not to the feature, so they can't be expanded. New work can only come through new tickets, which get prioritized. Manager is happy because tickets get cleared. I'm happy because I can fight scope creep by pointing to my sprint and asking which tickets they want to bump for their new scope creep. Tickets like "implement X feature" with a 2 week estimate are a landmine for engineers because it's broad enough for the scope to expand infinitely, and it starts to look like nothing is getting done to management.

brailsafe 4y ago
This is similar to what I've been thinking, but on the frontend. Tests/Design changes/Core JS for x. Seems like the only way.