36910Re: [scrumdevelopment] Re: Tracking number of passed story acceptance criteria during the sprint
- Mar 1, 2009lindgrenf wrote:
>> Why does the team jump to horizontal splitting?It's easier because they haven't developed the skill of small vertical
> Because it's easier i guess. I think it has to do with our vertical
> slices being pretty deep at times. We're developing a distributed
> system with a central server where configuration is done, distributed
> nodes in the network and several different clients for handhelds. So
> far we've tried to require initial slicing to cover at least one of
> the clients, the distributed network node, and of course the
> configuration. Without these components, there would not be any
> business value to the story. Given our separate software components,
> it is just a too natural splitting boundary to resist once the
> vertical slice is thin enough.
Why do you say "of course?" I would consider making the configuration a
separate story. Handling the most common configuration, with hardwired
parameters, is story enough. There /is/ business value in it, even if
it's not in a state that you want to ship. See Jeff Patton's bit on
"You Aren't Gonna Ship It." Then, as part of allowing a different value
for one configuration parameter, I would add the ability to configure
> Our default definition of done also includes documenting the addedWhy not? Does the feature not work if the documentation isn't written?
> feature for both administrators and in general product documentation.
> I know that we could split the documentation parts into separate
> stories by adding a story for: As a novice administrator I want to be
> able to learn howto..., and a story for: As a solution architect I
> want to read the documentation for the feature, so that I can better
> configure my deployment. However, this IMO would mean that the real
> story is not really done-done.
It may be something that must be done before delivery, but I would
make it one or more stories, one for each target reader. Another
possibility would be enhance the documentation for each slice added to
the feature. I'm of the opinion that design documentation is better
written after the fact, though.
>>> In practice we have never accepted a single story that is biggerI think that velocity will increase faster if you reduce the story size.
>>> half of the average team velocity, and when taking on one of
>>> larger stories we always try to swarm around the big story in the
>>> beginning of the sprint to reduce the risk of having a failed
>>> with a partially done story. In such a case, I think that showing
>>> partial, but real, progress could help us to discover problems
>> Oof! That's a huge story, to me.
> Well, we're a small team with a majority of junior developers and
> we're running two week sprints. My gut feeling is that the stories
> are not that big, rather the velocity is lower than for a larger team
> with a longer sprint. My hope is that we will improve while not
> letting the stories to grow bigger, and then the relative size
> between maximum story size and velocity should improve as well.
>> Do you have any good testers on this team? When the P.O. isAre the developers good testers? It's my experience that good testers
>> the story, do they not ask what is the acceptance criteria? Is the
>> of the story so hard to discern? If so, how does the P.O. expect
>> programmers to get it right?
> Good testers or not, the team will ask the P.O. about the acceptance
> criteria. It's just that the level of detail that we would get during
> sprint may not be complete. The way we deal with it is by
> communicating with the P.O. daily through oút the sprint, refining
> the acceptance criteria as we go. Maybe we're just good enough at
> handling it this way, that the issue remains hidden. Which brings me
> back to the idea of exposing the issue by visualizing it throughout
> the sprint.
are better than developers at asking the pertinent questions. It's
fine, though, to refine things through the sprint. You should see that
in changes to the acceptance tests.
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
- << Previous post in topic Next post in topic >>