Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] Re: Tracking number of passed story acceptance criteria during the sprint

Expand Messages
  • George Dinwiddie
    ... It s easier because they haven t developed the skill of small vertical stories. Why do you say of course? I would consider making the configuration a
    Message 1 of 74 , Mar 1, 2009
    • 0 Attachment
      lindgrenf wrote:

      >> Why does the team jump to horizontal splitting?
      > 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.

      It's easier because they haven't developed the skill of small vertical

      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
      that parameter.

      > Our default definition of done also includes documenting the added
      > 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.

      Why not? Does the feature not work if the documentation isn't written?
      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 bigger
      > than
      >>> half of the average team velocity, and when taking on one of
      > these
      >>> 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
      > sprint
      >>> with a partially done story. In such a case, I think that showing
      > the
      >>> partial, but real, progress could help us to discover problems
      >>> earlier.
      >> 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.

      I think that velocity will increase faster if you reduce the story size.

      >> Do you have any good testers on this team? When the P.O. is
      >> describing
      >> the story, do they not ask what is the acceptance criteria? Is the
      >> crux
      >> of the story so hard to discern? If so, how does the P.O. expect
      >> the
      >> 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 the developers good testers? It's my experience that good testers
      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

      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
    • Ron Jeffries
      Hello, Robert. On Saturday, March 7, 2009, at 1:51:27 PM, you ... Maybe next game, with that point. :) Ron Jeffries www.XProgramming.com
      Message 74 of 74 , Mar 7, 2009
      • 0 Attachment
        Hello, Robert. On Saturday, March 7, 2009, at 1:51:27 PM, you

        > What seemed odd to me about your game is that it seemed to involve
        > no decision making during play. I had been expecting to see some kind of
        > evaluation and some kind of decision-making about making changes.

        Maybe next game, with that point. :)

        Ron Jeffries
        Attend our CSM Plus Course!
        The model that really matters is the one that people have in
        their minds. All other models and documentation exist only to
        get the right model into the right mind at the right time.
        -- Paul Oldfield
      Your message has been successfully submitted and would be delivered to recipients shortly.