Hello, Charles. On Wednesday, February 2, 2011, at 8:00:01 PM,
>> 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?
> Approach 1: Spike Story
> 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.
Yes, though a spike, because its value is also not obvious to the
PO, usually needs to be small. I took you to be saying that the
framework was such that it was going to be impacting velocity for a
long time. If so ... that's how long things are going to take, and
I'd estimate them.
If the PO would give me extra time to learn the framework, and you'd
hope to hell they would at least understand that need, then I would
still use that time by building the real features we need, since
that would focus my learning.
I always build new things by starting with a spike of a half-day or
less. I would often just bake it into my estimate.
I do share Adam's concern that the whole framework thing is a bad
idea, especially since the starting premise here is that it's going
to take a long time and slow us down. It's not easy to see why we'd
choose something to slow us down.
I also share his bias that most frameworks do in fact slow us down,
unless they are very specialized. I would use a PDF-writing
framework. I would use OpenGL. I would not use a general application
focused framework unless it was clear that it would speed me up
within the first week or two.
> Approach 2: Dev Item
> This is where I walk into territory that I'm not terribly comfortable in just
> 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
No one can put anything into the Sprint Backlog but the Product
Owner, as far as I know. No doubt Dan or someone has another theory.
Note, however, that Scrum can be used to manage anything, including
cutting the grass at the stadium, so it can certainly be used that
way. I do not advise Dev Stories, which sound exactly like Technical
Stories to me, for two important reasons:
As your question reflects, they are difficult for the PO to
All too often, if something is so large that the team wants to
make it a "Dev Item", what is really going on is that they need to
up their game in doing things incrementally. This is also one of
The team can of course break that work into tasks (if they insist on
making the mistake of breaking the work into tasks) and whether they
do so or not, they can choose to do the work by any means necessary,
such as using the framework.
That's what I mean about baking the use of the framework into the
individual stories. If we're going to use the framework on this
story, and it is going to take another day because we're doing it,
then that's the estimate.
> 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.
Yes, and bake it into the estimates of the stories / features /
Product Backlog items, however this estimation is done.
> 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.
This makes them sound like there are many items that are discernibly
separate from individual stories. I would prefer not to do that.
> 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.
Yes. I personally believe that they can almost always be avoided.
That said, I completely agree with not counting them as velocity. I
think that Dan, and Roy, and probably others would count them. We've
talked about the pros and cons of that. I would not count them.
> 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.
Note that in real Scrum the PO has the sole responsibility for
getting the best possible product by the date. Dev stories make her
job much harder, as no one (I mean no one) can properly prioritize
them against a revenue- or benefit-bearing feature.
Since as far as I know it is (almost?) always possible to do the
technical work incrementally, I never recommend Dev Stories as a
> 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.
I believe the main tenet of Scrum that this impacts is that only the
PO can select things into the Sprint Backlog. While it is true that
the team can build the software using any technical approach they
choose (subject to whatever the company enforces, which is probably
also against a Scrum tenet about self-organization), the necessity
of doing "Dev Stories" raises a very serious question about the
team's ability to execute Scrum well.
Most teams cannot execute Scrum well right out of the box, and in
fact I would bet that most cannot execute Scrum well by my standards
at all. So this is not a fatal flaw, since most Scrum teams probably
get benefit from Scrum.
"Dev Stories" are, however, almost always evidence that the team
would benefit from learning more about working incrementally.
Some things are impossible. And some things people say are
impossible are impossible because they don't know how to do them.
-- Ron Loyd