> Daily standup
Change them so that people talk about what is blocked then.
> Scrum master
Tricky, like anyone who doesn't want to adapt.
> Technical debt
Create tickets for debt, put them on the backlog.
> Poor product owners
Tricky.
Change them so that people talk about what is blocked then.
> Scrum master
Tricky, like anyone who doesn't want to adapt.
> Technical debt
Create tickets for debt, put them on the backlog.
> Poor product owners
Tricky.
That will risk making a huge technical debt section in the backlog that will find it hard to get priority. It's better to condition new features/bugfixes on the cleanup that caused them. "I can add this feature in 1 day but will need 4 days to clean it up. So my estimate is a week." I constantly nag developers to do this when they find that they are pressed for time and want to make a hack.
-"I'm nearly done but I can't find a nice way of doing this because of an existing code smell so I'm considering adding another smell"
-"Did you ever find that this was NOT the case?"
-"No..."
-"So do you always double or triple your estimates so you know you can comfortably refactor"
-"No..."
I think this is a disease of Scrum. Too short estimates exist because developers pat themselves on the back for finishing things quickly.
Keep technical debt in separate tasks to make the tech debt visible and to keep management accountable for not making efforts to get rid of it.