50223Re: [scrumdevelopment] Refactoring type work in Scrum
- Feb 2, 2011Ron,
Thanks for the thorough answer.
Let's change the scenario a bit.
Now the dev team has decided that it is time to move from one framework that it uses, to another one(I'm going to leave out the reason, but let's assume it's a pretty good technical decision, unless you feel your answer depends on the reason). They estimate that this will increase the size of new backlog items that exercise code that uses the old framework for a while, as they transition over to the new framework. Some ramp up time, if you will, on the new framework. They are not doing a wholesale change. They are only using the new framework for new backlog items that would normally involve code that exercises the old framework. I don't know if one would call this incremental refactoring or not. I'm not sure what to call it.
In the context of Scrum, and based on your previous answer, does the team then just estimate the size of these backlog items taking into account some extra ramp up time for each?
The main theme of many of these scenarios is technical work on the system under development that cannot be successfully sold to the PO as adding enough business value to bring the technical work to the top of the backlog. Have you ever seen examples of this technical work that cannot be attached to new backlog items, but still should probably be completed for the health of the system under development, or possibly to help increase overall velocity/quality in the future, or possibly some other wise reason?
(I'm not talking re-writes of major portions of a system here.)(Also, in case you're wondering, I'm not about to advocate the use of the term "Technical Story" or anything like that)
Charles Bradley, CSM, PSM I
Experienced Scrum Coach
My blog: http://scrumcrazy.wordpress.com/
- << Previous post in topic Next post in topic >>