3 ms·

> 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

• alkonaut 7y ago
  > Create tickets for debt, put them on the backlog. 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.
  • postfacto 7y ago
    That will just lead to stories to change something simple the color of a button taking 3 days because you hit a tech debt minefield refactoring. You don’t want someone looking at JIRA and seeing it took you 3 days to change a simple button color. 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.