to Matt McClure:
> Looking at some of our tasks, I see things like:
> Code changes to component X.
> Code changes to component Y.
> I think this smells of overthinking the design during iteration
planning. I think I will coach the team to think about
> tasks/substories more like:
> Code subfeature A.
> Code subfeature B.
>Looking at the stories that our PO put at the top of his list, each of
them could have been further decomposed into smaller
>stories that would represent demonstrable progress. In practice, the
team is approaching the requested stories by implementing
>the substories even though they weren't planned that way.
Refining stories sounds like a promising approach, as the substories are
definitely easier to relate to the larger story/feature/system. I
somehow remembered a small story told in school (a long time ago!). In
the story two kids were asked to draw a straight line in sand. The first
started, but failed miserably. The second started, and managed to
accomplish the task. When asked, how it was possible, the kid told
having looked at the target point all the time. The lesson of this could
be that it is easier to proceed, if one can relate one's doings with the
whole. Thinking about code changes would be more like the first one,
! Jyrki Wahlstedt