50217Refactoring type work in Scrum
- Feb 2 1:22 PMBennyou/Ron Jeffries(and whoever else wants to comment),
From the thread: "Break from sprinting - a strategy sprint"
> However the old stuff which has been isolated from is starting to getclunky, and we want to pre-empt inadequate performance by replacing these. The legacy parts have not been regression tested nor would the
> effort to regression test the size of this be business feasible andthis is scaring developers. They are moving away from the hyper-productivity that they are used to and trying to make fixes in area which sees
> much less visible business value be delivered. Businessdoes not understand the slow down of development of features.
This kind of thing sounds like technical debt or something like it (IMO, there is not one really accepted definition of technical debt).
One thing I believe you've advocated in the past is "attaching" refactoring (or other similar activities, I'll just call it refactoring for now, feel free to refine that term as necessary) to new work that comes into the Product Backlog, thus including that refactoring into the estimate.
Do you only estimate with the attached work, or do you give the PO two estimates (one with the attached work, another without)?
I'm curious what you advise in this kind of situation, especially when the Dev Team has a strong desire to do the refactoring work.
Charles Bradley, CSM, PSM I
Experienced Scrum Coach
My blog: http://scrumcrazy.wordpress.com/
- Next post in topic >>