50228Re: [scrumdevelopment] Refactoring type work in Scrum
- Feb 2, 2011
Approach 1: Spike Story>
> > 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?
> In the kindest possible way: is there any other approach that could
> work? If we didn't include this time, wouldn't we fall behind
> immediately and also ship a new crappy system instead of the old
> crappy system?
I think, in some of these situations, you could argue that doing a spike story to get ramped up on the newer framework will help remove risk from estimating backlog items that use the new framework. OTOH, removing large risk and "ramp up time" are not exactly the same thing, so maybe this is not a valid approach. In this situation, you'd estimate the Spike Story separately.
Approach 2: Dev Item
This is where I walk into territory that I'm not terribly comfortable in just yet.
Here is one other approach(based on some statements in the Scrum Guide) I've dabbled with in the past when coaching teams. Maybe I was going off the reservation, or maybe I stumbled onto something interesting. Not that this approach is not specifically stated in the Scrum Guide, though I think it is a customization within the Scrum Framework that is also consistent with Scrum principles (again as defined in the guide).
In the past, I've dabbled with the concept of what I'll call "Dev Items", but there is probably a better term for it. These "Dev Items" are essentially one or more tasks that the dev team creates in a Sprint Backlog. These items are often not specifically related to what a specific backlog item describes. They are more related to how the team decides to create a potentially shippable product increment from the current Product Backlog items. "...Teams are also self-organizing. No one – not even the ScrumMaster -tells the Team how to turn Product Backlog into increments of shippable functionality..."[Scrum Guide quote] Further, the dev team defines and makes visible, the "definition of done."
As such , as it relates to the "new framework" scenario I've described, if the dev team feels like they need to use a new framework going forward, they can do so whenever they want to, whether or not the PO is ok with it.
Interesting notes about Approach #2:
1. I coach dev teams that these dev items MUST be made visible in the Sprint Backlog, and MUST be communicated to the PO. The amount of time a team spends on Dev Items should be a collaboration/negotiation between the team and PO, but in the end, the dev team makes the final decision.
2. I coach teams that, because these items are not User Stories, they do not count towards velocity. As such, their velocity might suffer, and that will be made visible and should be discussed openly as well. This includes accounting for velocity assumptions used for Release Planning, Sprint Planning, etc.
3. Because all of these decision are made visible, dev teams should be careful to only use this time for things that can be well justified to decision makers and whoever ultimately "funds" the team. If the PO has a direct impact on "funding" the team, then you'd better keep her happy.
I don't have this entire thing worked out, and I don't intend to be violating some important tenant of Scrum, either. If anyone feels as if I am, I'd certainly be interested in your thoughts on the subject.
Charles Bradley, CSM, PSM I
Experienced Scrum Coach
My blog: http://scrumcrazy.wordpress.com/
- << Previous post in topic Next post in topic >>