On Wed, Feb 2, 2011 at 3:57 PM, Charles Bradley - Scrum Coach CSM PSM
I <chuck-lists2@...> wrote:
> 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.
It is worth considering what we can do without using a framework for
exactly this reason (That it can become hard to change.) When we use
frameworks badly they create more work than they save. I see this
happen all the time with popular frameworks (Spring. Hibernate.) When
we use frameworks well we insulate our code from them by abstracting
out the details so that replacing them is trivial.
My rule of thumb here is that I don't use frameworks unless they have
one specific thing that they do really well and that thing is nearly
exactly what I am trying to do (e.g. JUnit for testing.) Otherwise I
see adopting the framework as a risk that I am going to get stuck
along the wrong road somewhere. So, I would just code it myself. Also,
it becomes fairly easy to incorporate the framework later once you
determine that what you decided to do is nearly exactly what it does.
> 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?
Yes and no. I would expect them to estimate based on what they think
it is going to take to complete the item, but I would also expect the
PO to challenge things that seemed inordinately expensive or that
weren't obviously valuable.
> 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?
"There is your sign," as they say. If you can't sell it to the PO you
aren't going to sell it to me. Why should the customer pay for a poor
technical decision you made somewhere up the line? That sounds like
your problem to me.
If you were building a house for me and at the last minute you decided
to install a different kind of roof, would you expect to be able to
write me a bill for both roofs?