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

Re: Non-Feature Things...

Expand Messages
  • Petri Heiramo
    Hi, ... Henrik already suggested one nice way to get it into the backlog. I might also suggest the following as an alternative. Define a story The system can
    Message 1 of 5 , May 9, 2007
    • 0 Attachment
      Hi,

      > How do people handle things like load tests, parallel tests, etc.
      > They're not part of some discrete feature, other than something non-
      > functional like "the system has to work." They're not normally
      > something product owners would bring up. For example, it would make
      > sense on my current project to run the new system in parallel with the
      > old for a few days, then compare results. This involves a bunch of 2
      > or less tasks.

      Henrik already suggested one nice way to get it into the backlog. I
      might also suggest the following as an alternative.

      Define a story "The system can handle this and that much traffic in a
      defined timeframe." In order to resolve that requirement, the team
      obviously needs to identify how well the system is actually performing
      and set up some kind of test (i.e. the load test we want to have in
      place) to make sure that the performance stays at desired level
      throughout the development. If the team discovers that the performance
      is not satisfactory, they will have to figure out what to do. If they
      can't fix it in the sprint the story is assigned to, they can
      re-estimate it and leave it for the next sprint (resulting in that
      story being "Not Done", but not ruining the rest of the sprint).

      The earlier you can insert that into the project, the easier it should
      be to meet that requirement. And once it's in there, the automated
      test takes care of keeping the performance at desired level (i.e. the
      test fails if some change would reduce the performance below desired).

      It can also be tiered like Henrik suggested into a spike part and then
      fixing it. If you feel that the fixing part is difficult to estimate,
      don't estimate it until you've done the spike. :) After all, you might
      not even have a problem.

      > something non-
      > functional like "the system has to work."

      Btw, I partially disagree with this. I think many of them _are_
      functional, by defining operational performance the system must meet.
      Therefore it is possible to come up with stories to cover them. Then
      of course there are things that are truly non-functional, like coding
      conventions, but those are an entirely different matter.


      Yours, Petri

      Petri Heiramo
      Process Improvement Manager
      SYSOPENDIGIA Plc., Finland
    Your message has been successfully submitted and would be delivered to recipients shortly.