50219Refactoring type work in Scrum
- Feb 2, 2011Bennyou/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 toThis kind of thing sounds like technical debt or something like it (IMO, there is not one really accepted definition of technical debt).
> get clunky, 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 and
> this 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. Business
> does not understand the slow down of development of features.
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. I believe you've made the point also that the "attached work" should be closely related (maybe in the same part of the system) to the new work in order to justify attaching the work.
Do you only estimate with the attached work, or do you give the PO two estimates (one with the attached work, another without)?
I think you've also advocated trying to "sell" the business value of the attached work to the PO. What do you advise when the PO doesn't want to do the attached work, but the Dev Team really feels the attached work is justified to help improve future productivity?
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 but the PO can't be sold.
Charles Bradley, CSM, PSM I
Experienced Scrum Coach
My blog: http://scrumcrazy.wordpress.com/
- << Previous post in topic Next post in topic >>