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

Non-functional requirements

Expand Messages
  • Wolfgang Schulze Zachau
    We recently had a sprint calling for several reports to be implemented into an application. In the sprint review the reports were demonstrated. One of them ran
    Message 1 of 18 , May 3, 2006
    • 0 Attachment

      We recently had a sprint calling for several reports to be implemented into an application. In the sprint review the reports were demonstrated. One of them ran extremely slow (about 5-10 minutes) but did eventually produce the results.

      From there ensued a bit of a debate on whether this slow performance was a bug or not. Eventually we agreed that it wasn’t and that an item would be included in the next sprint to look at options getting this report to work faster.

      My question here to the group is: how do you guys handle non-functional requirements? As far as I can see they can make a huge difference on the size/complexity of a user story or feature. More often than not, however, they are not documented at all during the building of the product and/or sprint backlog. There only seems to be some sort of general silent agreement that certain performance figures are acceptable whereas others are not.

      Do you insist on having these parameters documented by the PO ? Is it the responsibility of the team to get that information during the sprint planning meeting ? Or maybe during the estimation phase?

       

      Regards,

      Wolfgang Schulze-Zachau
      IT Manager
      mobilefun
      www.mobilefun.co.uk
      0870 420 4001 or 0870 429 9673
      mobile 0777 3385 905

       

    • Wolfgang Schulze Zachau
      We recently had a sprint calling for several reports to be implemented into an application. In the sprint review the reports were demonstrated. One of them ran
      Message 2 of 18 , May 3, 2006
      • 0 Attachment

        We recently had a sprint calling for several reports to be implemented into an application. In the sprint review the reports were demonstrated. One of them ran extremely slow (about 5-10 minutes) but did eventually produce the results.

        From there ensued a bit of a debate on whether this slow performance was a bug or not. Eventually we agreed that it wasn’t and that an item would be included in the next sprint to look at options getting this report to work faster.

        My question here to the group is: how do you guys handle non-functional requirements? As far as I can see they can make a huge difference on the size/complexity of a user story or feature. More often than not, however, they are not documented at all during the building of the product and/or sprint backlog. There only seems to be some sort of general silent agreement that certain performance figures are acceptable whereas others are not.

        Do you insist on having these parameters documented by the PO ? Is it the responsibility of the team to get that information during the sprint planning meeting ? Or maybe during the estimation phase?

         

        Regards,

        Wolfgang Schulze-Zachau
        IT Manager
        mobilefun
        www.mobilefun.co.uk
        0870 420 4001 or 0870 429 9673
        mobile 0777 3385 905

         

      • Keith Sader
        IMO you have stumbled across a latent functional requirement. I.e. the user story would be that he XYZ report should run in under X seconds. Put this in the
        Message 3 of 18 , May 3, 2006
        • 0 Attachment
          IMO you have stumbled across a latent functional requirement.  I.e. the user story would be that he XYZ report should run in under X seconds.  Put this in the backlog, assign the story points, and you should be good to go.

          Maybe performance metrics should be part of the conversations during the sprint planning?

          thanks,

          On 5/3/06, Wolfgang Schulze Zachau < wolfgang@...> wrote:

          We recently had a sprint calling for several reports to be implemented into an application. In the sprint review the reports were demonstrated. One of them ran extremely slow (about 5-10 minutes) but did eventually produce the results.

          From there ensued a bit of a debate on whether this slow performance was a bug or not. Eventually we agreed that it wasn't and that an item would be included in the next sprint to look at options getting this report to work faster.

          My question here to the group is: how do you guys handle non-functional requirements? As far as I can see they can make a huge difference on the size/complexity of a user story or feature. More often than not, however, they are not documented at all during the building of the product and/or sprint backlog. There only seems to be some sort of general silent agreement that certain performance figures are acceptable whereas others are not.

          Do you insist on having these parameters documented by the PO ? Is it the responsibility of the team to get that information during the sprint planning meeting ? Or maybe during the estimation phase?

           

          Regards,

          Wolfgang Schulze-Zachau
          IT Manager
          mobilefun
          www.mobilefun.co.uk
          0870 420 4001 or 0870 429 9673
          mobile 0777 3385 905




          --
          Keith Sader
          ksader@...
          http://www.saderfamily.org/roller/page/ksader
        • Ron Jeffries
          ... If you get the info, build to it. If you don t, and don t like the results, write a new backlog item saying make report 371 faster . Normal order of the
          Message 4 of 18 , May 3, 2006
          • 0 Attachment
            On Wednesday, May 3, 2006, at 11:30:40 AM, Wolfgang Schulze Zachau wrote:

            > My question here to the group is: how do you guys handle non-functional
            > requirements? As far as I can see they can make a huge difference on the
            > size/complexity of a user story or feature. More often than not, however,
            > they are not documented at all during the building of the product and/or
            > sprint backlog. There only seems to be some sort of general silent agreement
            > that certain performance figures are acceptable whereas others are not.

            > Do you insist on having these parameters documented by the PO ? Is it the
            > responsibility of the team to get that information during the sprint
            > planning meeting ? Or maybe during the estimation phase?

            If you get the info, build to it. If you don't, and don't like the
            results, write a new backlog item saying "make report 371 faster".
            Normal order of the day, either way.

            Ron Jeffries
            www.XProgramming.com
            Analysis kills spontaneity.
            The grain once ground into flour germinates no more. -- Henri Amiel
          • David A Barrett
            ... Saying sionara to discussions of this nature is one of the key benefits of Scrum, in my opinion. I can t see where it matters whether the slow performance
            Message 5 of 18 , May 3, 2006
            • 0 Attachment
              >From there ensued a bit of a debate on whether this slow performance was a
              >bug or not. Eventually we agreed that it wasn't and that an item would be
              >included in the next sprint to look at options getting this report to work
              >faster.

              Saying sionara to discussions of this nature is one of the key benefits of
              Scrum, in my opinion.

              I can't see where it matters whether the slow performance is bug. Making
              the report run faster is going to take time, and that time won't be
              available to do other things. So, even if it is a bug, I'd still put it in
              the PB and let the PO decide if it's worth fixing or not. End of
              discussion.

              In the old waterfall world, we used to get into this debate all the time.
              Why? Because there was an implied agreement that anything that was a bug
              was the development team's responsibility to fix without impacting the
              delivery schedule. The only way that the team could get extra time to
              change it was convince everyone that it was an enhancement. The users, on
              the other hand, wanted everything to be a bug (or some deviation from the
              agreed upon requirements) so that they could get it without paying a time
              (or cost) penalty.

              Dave Barrett,
              Lawyers' Professional Indemnity Company
            • Ron Jeffries
              ... Yes. To all the agile methods I know, in fact ... ... Exactly. The software isn t doing what we want. PO decides whether to spend on it or not. End of
              Message 6 of 18 , May 3, 2006
              • 0 Attachment
                On Wednesday, May 3, 2006, at 2:00:03 PM, David A Barrett wrote:

                > Saying [sayonara] to discussions of this nature is one of the key
                > benefits of Scrum, in my opinion.

                Yes. To all the agile methods I know, in fact ...

                > I can't see where it matters whether the slow performance is bug.
                > Making the report run faster is going to take time, and that time
                > won't be available to do other things. So, even if it is a bug,
                > I'd still put it in the PB and let the PO decide if it's worth
                > fixing or not. End of discussion.

                Exactly. The software isn't doing what we want. PO decides whether
                to spend on it or not. End of discussion. Marvelously elegant.

                > In the old waterfall world, we used to get into this debate all
                > the time. Why? Because there was an implied agreement that
                > anything that was a bug was the development team's responsibility
                > to fix without impacting the delivery schedule. The only way that
                > the team could get extra time to change it was convince everyone
                > that it was an enhancement. The users, on the other hand, wanted
                > everything to be a bug (or some deviation from the agreed upon
                > requirements) so that they could get it without paying a time (or
                > cost) penalty.

                Yes. Which is absurd on the face of it, as if time could somehow be
                created. Do you want it fixed, or not, that's the question. If you
                do, what are you going to take off the table?

                Ron Jeffries
                www.XProgramming.com
                We know less about the project today than at any time in the future.
                -- Chet Hendrickson
                You mean today is the dumbest day of the rest of my life?
                -- Ron Jeffries
              • Wolfgang Schulze Zachau
                This isn t about bug or not, this is about non-functional requirements, i.e. parameters to an application that determine the environment or performance, such
                Message 7 of 18 , May 4, 2006
                • 0 Attachment

                  This isn’t about bug or not, this is about non-functional requirements, i.e. parameters to an application that determine the environment or performance, such as “can be run by 50 people simultaneously without impact

                  on the performance”, “can process 2000 orders per day”, “is suitable for visually impaired people” (what is the definition of “suitable” ?).

                  With all the benefits that it brings, SCRUM also introduces a tendency towards “quick fixes”. If the product owner starts a new product by building a prototype that is just good enough to run on one desktop PC for one user, etc. and none of the non-functional requirements are defined, then rolling out that application into usage for 20 or 200 or 2000 users will most likely end up in disaster.

                  This is a bit like using the right kind of vehicle for transporting goods. If one goes shopping for a family, a small car might be enough. If one is about to deliver 20 tons of groceries to a supermarket, a big truck is needed. And no matter what efforts are made, a small family car cannot be converted into a big truck. It is a fundamentally different design. Likewise it wouldn’t make much sense to use the truck to do the shopping.

                  In the case of the report, if the requirement to run in a specific limited time would have been known up front, we wouldn’t have wasted time building a report that wasn’t good enough. There are lots of examples I am sure where a certain amount of up-front design work ensures that the final product is fit for the purpose. But that can only take place if the non-functional requirements are captured. So how do you guys go about capturing them, especially of the product backlog does not contain them?

                  Regards,

                   

                  Wolfgang


                  From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Ron Jeffries
                  Sent: 03 May 2006 20:37
                  To: scrumdevelopment@yahoogroups.com
                  Subject: Re: [scrumdevelopment] Re: Non-functional requirements

                   

                  On Wednesday, May 3, 2006, at 2:00:03 PM, David A Barrett wrote:

                  > Saying [sayonara] to discussions of this nature is one of the key
                  > benefits of Scrum, in my opinion.

                  Yes. To all the agile methods I know, in fact ...

                  > I can't see where it matters whether the slow performance is bug.
                  > Making the report run faster is going to take time, and that time
                  > won't be available to do other things. So, even if it is a bug,
                  > I'd still put it in the PB and let the PO
                  decide if it's worth
                  > fixing or not. End of discussion.

                  Exactly. The software isn't doing what we want. PO decides whether
                  to spend on it or not. End of discussion. Marvelously elegant.

                  > In the old waterfall world, we used to get into this debate all
                  > the time. Why? Because there was an implied agreement that
                  > anything that was a bug was the development team's responsibility
                  > to fix without impacting the delivery schedule. The only way that
                  > the team could get extra time to change it was convince everyone
                  > that it was an enhancement. The users, on the other hand, wanted
                  > everything to be a bug (or some deviation from the agreed upon
                  > requirements) so that they could get it without paying a time (or
                  > cost) penalty.

                  Yes. Which is absurd on the face of it, as if time could somehow be
                  created. Do you want it fixed, or not, that's the question. If you
                  do, what are you going to take off the table?

                  Ron Jeffries
                  www.XProgramming.com
                  We know less about the project today than at any time in the future.
                    -- Chet Hendrickson
                  You mean today is the dumbest day of the rest of my life?
                    -- Ron Jeffries


                • Ron Jeffries
                  ... OK. The fact that you said this probably threw us off. Apologies for thinking about bugs. From there ensued a bit of a debate on whether this slow
                  Message 8 of 18 , May 4, 2006
                  • 0 Attachment
                    On Thursday, May 4, 2006, at 4:10:15 AM, Wolfgang Schulze Zachau wrote:

                    > This isn't about bug or not, this is about non-functional requirements, i.e.
                    > parameters to an application that determine the environment or performance,
                    > such as "can be run by 50 people simultaneously without impact
                    > on the performance", "can process 2000 orders per day", "is suitable for
                    > visually impaired people" (what is the definition of "suitable" ?).

                    OK. The fact that you said this probably threw us off. Apologies for
                    thinking about bugs.

                    From there ensued a bit of a debate on whether this slow
                    performance was a bug or not. Eventually we agreed that it wasn't
                    and that an item would be included in the next sprint to look at
                    options getting this report to work faster.

                    > With all the benefits that it brings, SCRUM also introduces a tendency
                    > towards "quick fixes". If the product owner starts a new product by building
                    > a prototype that is just good enough to run on one desktop PC for one user,
                    > etc. and none of the non-functional requirements are defined, then rolling
                    > out that application into usage for 20 or 200 or 2000 users will most likely
                    > end up in disaster.

                    This would be a bit unlike the Scrum that I know about. The point of
                    each Sprint is to produce something that is at least potentially
                    deployable. It's best to be aware of all the requirements. On the
                    other hand, it's best to ignore a lot of them during the first
                    implementation.

                    My point and that of other posters was that if in fact you think of
                    a non-functional requirement early on, mention it, and if you don't
                    think of it until later, schedule it for a future Sprint. Either
                    way, it's not an anomaly, it's just part of the natural process.

                    In addition, the best way to build something that has to be
                    efficient probably still is to build it, and then make it efficient.
                    Piling too many non-functional requirements on the initial
                    implementation of something is likely to bog you down.

                    > This is a bit like using the right kind of vehicle for transporting goods.
                    > If one goes shopping for a family, a small car might be enough. If one is
                    > about to deliver 20 tons of groceries to a supermarket, a big truck is
                    > needed. And no matter what efforts are made, a small family car cannot be
                    > converted into a big truck. It is a fundamentally different design. Likewise
                    > it wouldn't make much sense to use the truck to do the shopping.

                    Software, it turns out, is very much not like a truck. In software,
                    if we build a small car this iteration, we can make it larger, or
                    faster, in the next. It takes years to design and build an
                    automotive vehicle, and years to pay for one. Software's not like
                    that: we can make it better.

                    > In the case of the report, if the requirement to run in a specific limited
                    > time would have been known up front, we wouldn't have wasted time building a
                    > report that wasn't good enough.

                    My guess is that this is very unlikely, and even if it were true,
                    it's very uncommon. It's quite rare to build something that works,
                    yet is not capable of optimization.

                    Sometimes, certainly, we might use a completely different
                    implementation. Suppose the report was to tell us the total dollar
                    value of all the transactions today, and we did billions of them.
                    Then it might not be feasible to add up all the transactions every
                    time someone wanted to know how we're doing. We might, instead, keep
                    a running total, and tick it up or down when a transaction comes in.

                    So it's good to know what's coming up. But the fundamental premise
                    of the Agile methods is that we won't know everything, and shouldn't
                    wait until we do. The value of getting the software concrete and in
                    hand now is higher than the value of getting it more nearly right
                    later.

                    > There are lots of examples I am sure where a
                    > certain amount of up-front design work ensures that the final product is fit
                    > for the purpose. But that can only take place if the non-functional
                    > requirements are captured. So how do you guys go about capturing them,
                    > especially of the product backlog does not contain them?

                    The point is that the /final/ product needs to be fit for the
                    purpose. If you want to put NF requirements into the backlog, go
                    ahead. Your primary problems with this will be that things in the
                    backlog need to be concrete, and that over-specifying initial
                    feature requirements will slow the project down, rather than make it
                    go faster as you're imagining.

                    "Make it fast" is not a valid backlog item, though "Make report 371
                    run in under 30 seconds" is. The latter can be said the first time
                    the report is asked for, and if it really matters, it should be. If
                    you don't say it, sometimes there'll be more work to do to get what
                    you want, but it is most commonly not RE-work, just MORE work, that
                    would have had to be done anyway.

                    Ron Jeffries
                    www.XProgramming.com
                    Hold on to your dream. --ELO
                  • Rick Simmons
                    A lot of what s been said here is valid, about putting NFs into the backlog, tackling things at the right time and depth, etc. I think a key take-away is that
                    Message 9 of 18 , May 4, 2006
                    • 0 Attachment
                      A lot of what's been said here is valid, about putting NFs into the
                      backlog, tackling things at the right time and depth, etc.

                      I think a key take-away is that it is the Scrum Master's
                      responsibility to see that the PO is covering all the bases. If the
                      PO isn't very techie and hasn't thought about NF's Scrum Master should
                      make her aware of the concept. (Or ask someone from the team to help
                      her out. "Hey, PO, these are some common types of NF's. Which of
                      these might be important to you now?") This provides the opportunity
                      to put *something* about it into the backlog.

                      Train your PO... help your PO!

                      /Rick Simmons
                    • Pascal Roy
                      When the customer writes a user story that goes into a sprint, he also specifies the criteria for accepting the said story. A performance criteria can be one
                      Message 10 of 18 , May 4, 2006
                      • 0 Attachment

                        When the customer writes a user story that goes into a sprint, he also specifies the criteria for accepting the said story. A performance criteria can be one of many criteria, usability might be another although that would be harder to automate. QA people typically help the customer define those criteria and very often work along with developers on automating tests that check all the criteria. These tests constitute a very valuable asset because they specify what the customer really wants in a non ambiguous form.  The beauty of automated tests is that they can’t be misinterpreted, they either work or don’t. Of course, automating all these criteria into tests is a lot of really hard work (right now, the tools available are very brittle and fairly difficult to learn). Even just thinking about the criteria is a lot of work but hey, somebody shouldn’t actually have an idea of how the software ought to behave before we actually start building it?.  

                         

                        Ideally, as developers, the best thing for us would be to have the automated acceptance tests available up front so we have a clear and testable target to continually check that the code we write actually meets the acceptance criteria. In practice, this is really hard to do, but it’s doable if the team commits to it…  

                         

                        Pascal Roy, ing./P.Eng., PMP

                        Vice-Président/Vice President

                        Elapse Technologies Inc.

                         

                        [url]    http://www.elapsetech.com

                        [email]  pascal.roy@...

                        [cell]   514-862-6836

                         

                         


                        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Wolfgang Schulze Zachau
                        Sent: 4 mai 2006 04:10
                        To: scrumdevelopment@yahoogroups.com
                        Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                         

                        This isn’t about bug or not, this is about non-functional requirements, i.e. parameters to an application that determine the environment or performance, such as “can be run by 50 people simultaneously without impact

                        on the performance”, “can process 2000 orders per day”, “is suitable for visually impaired people” (what is the definition of “suitable” ?).

                        With all the benefits that it brings, SCRUM also introduces a tendency towards “quick fixes”. If the product owner starts a new product by building a prototype that is just good enough to run on one desktop PC for one user, etc. and none of the non-functional requirements are defined, then rolling out that application into usage for 20 or 200 or 2000 users will most likely end up in disaster.

                        This is a bit like using the right kind of vehicle for transporting goods. If one goes shopping for a family, a small car might be enough. If one is about to deliver 20 tons of groceries to a supermarket, a big truck is needed. And no matter what efforts are made, a small family car cannot be converted into a big truck. It is a fundamentally different design. Likewise it wouldn’t make much sense to use the truck to do the shopping.

                        In the case of the report, if the requirement to run in a specific limited time would have been known up front, we wouldn’t have wasted time building a report that wasn’t good enough. There are lots of examples I am sure where a certain amount of up-front design work ensures that the final product is fit for the purpose. But that can only take place if the non-functional requirements are captured. So how do you guys go about capturing them, especially of the product backlog does not contain them?

                        Regards,

                         

                        Wolfgang


                        From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Ron Jeffries
                        Sent: 03 May 2006 20:37
                        To: scrumdevelopment@yahoogroups.com
                        Subject: Re: [scrumdevelopment] Re: Non-functional requirements

                         

                        On Wednesday, May 3, 2006, at 2:00:03 PM, David A Barrett wrote:

                        > Saying [sayonara] to discussions of this nature is one of the key
                        > benefits of Scrum, in my opinion.

                        Yes. To all the agile methods I know, in fact ...

                        > I can't see where it matters whether the slow performance is bug.
                        > Making the report run faster is going to take time, and that time
                        > won't be available to do other things. So, even if it is a bug,
                        > I'd still put it in the PB and let the PO
                        decide if it's worth
                        > fixing or not. End of discussion.

                        Exactly. The software isn't doing what we want. PO decides whether
                        to spend on it or not. End of discussion. Marvelously elegant.

                        > In the old waterfall world, we used to get into this debate all
                        > the time. Why? Because there was an implied agreement that
                        > anything that was a bug was the development team's responsibility
                        > to fix without impacting the delivery schedule. The only way that
                        > the team could get extra time to change it was convince everyone
                        > that it was an enhancement. The users, on the other hand, wanted
                        > everything to be a bug (or some deviation from the agreed upon
                        > requirements) so that they could get it without paying a time (or
                        > cost) penalty.

                        Yes. Which is absurd on the face of it, as if time could somehow be
                        created. Do you want it fixed, or not, that's the question. If you
                        do, what are you going to take off the table?

                        Ron Jeffries
                        www.XProgramming.com
                        We know less about the project today than at any time in the future.
                          -- Chet Hendrickson
                        You mean today is the dumbest day of the rest of my life?
                          -- Ron Jeffries



                      • Steven Gordon
                        The PO may be much better able to quantify the NFs after using the software. The PO may even have to demo it to potential users to get a good idea of what the
                        Message 11 of 18 , May 4, 2006
                        • 0 Attachment
                          The PO may be much better able to quantify the NFs after using the
                          software. The PO may even have to demo it to potential users to get a
                          good idea of what the NFs are for use in their world.

                          Another point is that many NFs are with respect to the environment
                          that the software will be deployed, which is often quite different
                          than the environments in which it is developed, tested, and demoed.
                          The organization may decide that the investment in such an environment
                          is not warranted until after the viability of the project has proven
                          out over several iterations of feedback.

                          Steven Gordon

                          On 5/4/06, Rick Simmons <simmons3k@...> wrote:
                          > A lot of what's been said here is valid, about putting NFs into the
                          > backlog, tackling things at the right time and depth, etc.
                          >
                          > I think a key take-away is that it is the Scrum Master's
                          > responsibility to see that the PO is covering all the bases. If the
                          > PO isn't very techie and hasn't thought about NF's Scrum Master should
                          > make her aware of the concept. (Or ask someone from the team to help
                          > her out. "Hey, PO, these are some common types of NF's. Which of
                          > these might be important to you now?") This provides the opportunity
                          > to put *something* about it into the backlog.
                          >
                          > Train your PO... help your PO!
                          >
                          > /Rick Simmons
                        • Wolfgang Schulze Zachau
                          I am sorry guys, but this is not where I am. I don’t have a QA team. I don’t have any fancy test tools that would allow me to set up tests that measure
                          Message 12 of 18 , May 4, 2006
                          • 0 Attachment

                            I am sorry guys, but this is not where I am. I don’t have a QA team. I don’t have any fancy test tools that would allow me to set up tests that measure non-functional performance criteria (and I won’t get them, either). Most of all, I don’t have a customer that will specify acceptance criteria for his stories. Which is exactly why I brought up the subject in the first place!

                            I have to deal with product backlog items such as “Fix queries to Bob’s satisfaction”, and when Bob is asked to tell us what that means, he says he isn’t quite sure and it won’t be that big and he really needs this to be done in the next sprint and because Bob is the boss, the team says “OK, we’ll do it”.

                            I then ask the team how they are going to estimate this and they say they trust Bob and therefore it’s this and that size. The actual requirements never get written down anywhere and when the whole thing comes up again in the sprint review, the team is pretty much at Bob’s mercy. If Bob was available during the sprint, then chances are the team could quiz him and they get it right. If Bob wasn’t available, well, take your guess.

                             

                            So once again, the question here: how do you elicit this important information from your customer ?

                            Regards,

                             

                            Wolfgang


                            From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Pascal Roy
                            Sent: 04 May 2006 15:25
                            To: scrumdevelopment@yahoogroups.com
                            Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                             

                            When the customer writes a user story that goes into a sprint, he also specifies the criteria for accepting the said story. A performance criteria can be one of many criteria, usability might be another although that would be harder to automate. QA people typically help the customer define those criteria and very often work along with developers on automating tests that check all the criteria. These tests constitute a very valuable asset because they specify what the customer really wants in a non ambiguous form.  The beauty of automated tests is that they can’t be misinterpreted, they either work or don’t. Of course, automating all these criteria into tests is a lot of really hard work (right now, the tools available are very brittle and fairly difficult to learn). Even just thinking about the criteria is a lot of work but hey, somebody shouldn’t actually have an idea of how the software ought to behave before we actually start building it?.  

                             

                            Ideally, as developers, the best thing for us would be to have the automated acceptance tests available up front so we have a clear and testable target to continually check that the code we write actually meets the acceptance criteria. In practice, this is really hard to do, but it’s doable if the team commits to it…  

                             

                            Pascal Roy, ing./P.Eng., PMP

                            Vice-Président/Vice President

                            Elapse Technologies Inc.

                             

                            [url]    http://www.elapsetech.com

                            [email]  pascal.roy@...

                            [cell]   514-862-6836

                             

                             


                            From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Wolfgang Schulze Zachau
                            Sent: 4 mai 2006 04:10
                            To: scrumdevelopment@yahoogroups.com
                            Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                             

                            This isn’t about bug or not, this is about non-functional requirements, i.e. parameters to an application that determine the environment or performance, such as “can be run by 50 people simultaneously without impact

                            on the performance”, “can process 2000 orders per day”, “is suitable for visually impaired people” (what is the definition of “suitable” ?).

                            With all the benefits that it brings, SCRUM also introduces a tendency towards “quick fixes”. If the product owner starts a new product by building a prototype that is just good enough to run on one desktop PC for one user, etc. and none of the non-functional requirements are defined, then rolling out that application into usage for 20 or 200 or 2000 users will most likely end up in disaster.

                            This is a bit like using the right kind of vehicle for transporting goods. If one goes shopping for a family, a small car might be enough. If one is about to deliver 20 tons of groceries to a supermarket, a big truck is needed. And no matter what efforts are made, a small family car cannot be converted into a big truck. It is a fundamentally different design. Likewise it wouldn’t make much sense to use the truck to do the shopping.

                            In the case of the report, if the requirement to run in a specific limited time would have been known up front, we wouldn’t have wasted time building a report that wasn’t good enough. There are lots of examples I am sure where a certain amount of up-front design work ensures that the final product is fit for the purpose. But that can only take place if the non-functional requirements are captured. So how do you guys go about capturing them, especially of the product backlog does not contain them?

                            Regards,

                             

                            Wolfgang


                            From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Ron Jeffries
                            Sent: 03 May 2006 20:37
                            To: scrumdevelopment@yahoogroups.com
                            Subject: Re: [scrumdevelopment] Re: Non-functional requirements

                             

                            On Wednesday, May 3, 2006, at 2:00:03 PM, David A Barrett wrote:

                            > Saying [sayonara] to discussions of this nature is one of the key
                            > benefits of Scrum, in my opinion.

                            Yes. To all the agile methods I know, in fact ...

                            > I can't see where it matters whether the slow performance is bug.
                            > Making the report run faster is going to take time, and that time
                            > won't be available to do other things. So, even if it is a bug,
                            > I'd still put it in the PB and let the PO
                            decide if it's worth
                            > fixing or not. End of discussion.

                            Exactly. The software isn't doing what we want. PO decides whether
                            to spend on it or not. End of discussion. Marvelously elegant.

                            > In the old waterfall world, we used to get into this debate all
                            > the time. Why? Because there was an implied agreement that
                            > anything that was a bug was the development team's responsibility
                            > to fix without impacting the delivery schedule. The only way that
                            > the team could get extra time to change it was convince everyone
                            > that it was an enhancement. The users, on the other hand, wanted
                            > everything to be a bug (or some deviation from the agreed upon
                            > requirements) so that they could get it without paying a time (or
                            > cost) penalty.

                            Yes. Which is absurd on the face of it, as if time could somehow be
                            created. Do you want it fixed, or not, that's the question. If you
                            do, what are you going to take off the table?

                            Ron Jeffries
                            www.XProgramming.com
                            We know less about the project today than at any time in the future.
                              -- Chet Hendrickson
                            You mean today is the dumbest day of the rest of my life?
                              -- Ron Jeffries




                          • Jeff Heinen
                            Does Bob participate in the sprint planning meeting, or does he just write backlog items and let the team take it from there? ________________________________
                            Message 13 of 18 , May 4, 2006
                            • 0 Attachment
                              Does Bob participate in the sprint planning meeting, or does he just write backlog items and let the team take it from there?


                              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Wolfgang Schulze Zachau
                              Sent: Thursday, May 04, 2006 8:23 AM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                              I am sorry guys, but this is not where I am. I don’t have a QA team. I don’t have any fancy test tools that would allow me to set up tests that measure non-functional performance criteria (and I won’t get them, either). Most of all, I don’t have a customer that will specify acceptance criteria for his stories. Which is exactly why I brought up the subject in the first place!

                              I have to deal with product backlog items such as “Fix queries to Bob’s satisfaction”, and when Bob is asked to tell us what that means, he says he isn’t quite sure and it won’t be that big and he really needs this to be done in the next sprint and because Bob is the boss, the team says “OK, we’ll do it”.

                              I then ask the team how they are going to estimate this and they say they trust Bob and therefore it’s this and that size. The actual requirements never get written down anywhere and when the whole thing comes up again in the sprint review, the team is pretty much at Bob’s mercy. If Bob was available during the sprint, then chances are the team could quiz him and they get it right. If Bob wasn’t available, well, take your guess.

                               

                              So once again, the question here: how do you elicit this important information from your customer ?

                              Regards,

                               

                              Wolfgang


                              From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Pascal Roy
                              Sent: 04 May 2006 15:25
                              To: scrumdevelopment@yahoogroups.com
                              Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                               

                              When the customer writes a user story that goes into a sprint, he also specifies the criteria for accepting the said story. A performance criteria can be one of many criteria, usability might be another although that would be harder to automate. QA people typically help the customer define those criteria and very often work along with developers on automating tests that check all the criteria. These tests constitute a very valuable asset because they specify what the customer really wants in a non ambiguous form.  The beauty of automated tests is that they can’t be misinterpreted, they either work or don’t. Of course, automating all these criteria into tests is a lot of really hard work (right now, the tools available are very brittle and fairly difficult to learn). Even just thinking about the criteria is a lot of work but hey, somebody shouldn’t actually have an idea of how the software ought to behave before we actually start building it?.  

                               

                              Ideally, as developers, the best thing for us would be to have the automated acceptance tests available up front so we have a clear and testable target to continually check that the code we write actually meets the acceptance criteria. In practice, this is really hard to do, but it’s doable if the team commits to it…  

                               

                              Pascal Roy, ing./P.Eng., PMP

                              Vice-Président/Vice President

                              Elapse Technologies Inc.

                               

                              [url]    http://www.elapsetech.com

                              [email]  pascal.roy@...

                              [cell]   514-862-6836

                               

                               


                              From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Wolfgang Schulze Zachau
                              Sent: 4 mai 2006 04:10
                              To: scrumdevelopment@yahoogroups.com
                              Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                               

                              This isn’t about bug or not, this is about non-functional requirements, i.e. parameters to an application that determine the environment or performance, such as “can be run by 50 people simultaneously without impact

                              on the performance”, “can process 2000 orders per day”, “is suitable for visually impaired people” (what is the definition of “suitable” ?).

                              With all the benefits that it brings, SCRUM also introduces a tendency towards “quick fixes”. If the product owner starts a new product by building a prototype that is just good enough to run on one desktop PC for one user, etc. and none of the non-functional requirements are defined, then rolling out that application into usage for 20 or 200 or 2000 users will most likely end up in disaster.

                              This is a bit like using the right kind of vehicle for transporting goods. If one goes shopping for a family, a small car might be enough. If one is about to deliver 20 tons of groceries to a supermarket, a big truck is needed. And no matter what efforts are made, a small family car cannot be converted into a big truck. It is a fundamentally different design. Likewise it wouldn’t make much sense to use the truck to do the shopping.

                              In the case of the report, if the requirement to run in a specific limited time would have been known up front, we wouldn’t have wasted time building a report that wasn’t good enough. There are lots of examples I am sure where a certain amount of up-front design work ensures that the final product is fit for the purpose. But that can only take place if the non-functional requirements are captured. So how do you guys go about capturing them, especially of the product backlog does not contain them?

                              Regards,

                               

                              Wolfgang


                              From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Ron Jeffries
                              Sent: 03 May 2006 20:37
                              To: scrumdevelopment@yahoogroups.com
                              Subject: Re: [scrumdevelopment] Re: Non-functional requirements

                               

                              On Wednesday, May 3, 2006, at 2:00:03 PM, David A Barrett wrote:

                              > Saying [sayonara] to discussions of this nature is one of the key
                              > benefits of Scrum, in my opinion.

                              Yes. To all the agile methods I know, in fact ...

                              > I can't see where it matters whether the slow performance is bug.
                              > Making the report run faster is going to take time, and that time
                              > won't be available to do other things. So, even if it is a bug,
                              > I'd still put it in the PB and let the PO decide if it's worth
                              > fixing or not. End of discussion.

                              Exactly. The software isn't doing what we want. PO decides whether
                              to spend on it or not. End of discussion. Marvelously elegant.

                              > In the old waterfall world, we used to get into this debate all
                              > the time. Why? Because there was an implied agreement that
                              > anything that was a bug was the development team's responsibility
                              > to fix without impacting the delivery schedule. The only way that
                              > the team could get extra time to change it was convince everyone
                              > that it was an enhancement. The users, on the other hand, wanted
                              > everything to be a bug (or some deviation from the agreed upon
                              > requirements) so that they could get it without paying a time (or
                              > cost) penalty.

                              Yes. Which is absurd on the face of it, as if time could somehow be
                              created. Do you want it fixed, or not, that's the question. If you
                              do, what are you going to take off the table?

                              Ron Jeffries
                              www.XProgramming.com
                              We know less about the project today than at any time in the future.
                                -- Chet Hendrickson
                              You mean today is the dumbest day of the rest of my life?
                                -- Ron Jeffries




                            • Wolfgang Schulze Zachau
                              Bob does participate in the sprint planning meeting. Regards, Wolfgang _____ From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com]
                              Message 14 of 18 , May 4, 2006
                              • 0 Attachment

                                Bob does participate in the sprint planning meeting.

                                 

                                Regards,

                                 

                                Wolfgang


                                From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Jeff Heinen
                                Sent: 04 May 2006 17:22
                                To: scrumdevelopment@yahoogroups.com
                                Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                                 

                                Does Bob participate in the sprint planning meeting, or does he just write backlog items and let the team take it from there?

                                 


                                From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Wolfgang Schulze Zachau
                                Sent: Thursday, May 04, 2006 8:23 AM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                                I am sorry guys, but this is not where I am. I don’t have a QA team. I don’t have any fancy test tools that would allow me to set up tests that measure non-functional performance criteria (and I won’t get them, either). Most of all, I don’t have a customer that will specify acceptance criteria for his stories. Which is exactly why I brought up the subject in the first place!

                                I have to deal with product backlog items such as “Fix queries to Bob’s satisfaction”, and when Bob is asked to tell us what that means, he says he isn’t quite sure and it won’t be that big and he really needs this to be done in the next sprint and because Bob is the boss, the team says “OK, we’ll do it”.

                                I then ask the team how they are going to estimate this and they say they trust Bob and therefore it’s this and that size. The actual requirements never get written down anywhere and when the whole thing comes up again in the sprint review, the team is pretty much at Bob’s mercy. If Bob was available during the sprint, then chances are the team could quiz him and they get it right. If Bob wasn’t available, well, take your guess.

                                 

                                So once again, the question here: how do you elicit this important information from your customer ?

                                Regards,

                                 

                                Wolfgang


                                From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Pascal Roy
                                Sent: 04 May 2006 15:25
                                To: scrumdevelopment@yahoogroups.com
                                Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                                 

                                When the customer writes a user story that goes into a sprint, he also specifies the criteria for accepting the said story. A performance criteria can be one of many criteria, usability might be another although that would be harder to automate. QA people typically help the customer define those criteria and very often work along with developers on automating tests that check all the criteria. These tests constitute a very valuable asset because they specify what the customer really wants in a non ambiguous form.  The beauty of automated tests is that they can’t be misinterpreted, they either work or don’t. Of course, automating all these criteria into tests is a lot of really hard work (right now, the tools available are very brittle and fairly difficult to learn). Even just thinking about the criteria is a lot of work but hey, somebody shouldn’t actually have an idea of how the software ought to behave before we actually start building it?.  

                                 

                                Ideally, as developers, the best thing for us would be to have the automated acceptance tests available up front so we have a clear and testable target to continually check that the code we write actually meets the acceptance criteria. In practice, this is really hard to do, but it’s doable if the team commits to it…  

                                 

                                Pascal Roy, ing./P.Eng., PMP

                                Vice-Président/Vice President

                                Elapse Technologies Inc.

                                 

                                [url]    http://www.elapsetech.com

                                [email]  pascal.roy@...

                                [cell]   514-862-6836

                                 

                                 


                                From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Wolfgang Schulze Zachau
                                Sent: 4 mai 2006 04:10
                                To: scrumdevelopment@yahoogroups.com
                                Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                                 

                                This isn’t about bug or not, this is about non-functional requirements, i.e. parameters to an application that determine the environment or performance, such as “can be run by 50 people simultaneously without impact

                                on the performance”, “can process 2000 orders per day”, “is suitable for visually impaired people” (what is the definition of “suitable” ?).

                                With all the benefits that it brings, SCRUM also introduces a tendency towards “quick fixes”. If the product owner starts a new product by building a prototype that is just good enough to run on one desktop PC for one user, etc. and none of the non-functional requirements are defined, then rolling out that application into usage for 20 or 200 or 2000 users will most likely end up in disaster.

                                This is a bit like using the right kind of vehicle for transporting goods. If one goes shopping for a family, a small car might be enough. If one is about to deliver 20 tons of groceries to a supermarket, a big truck is needed. And no matter what efforts are made, a small family car cannot be converted into a big truck. It is a fundamentally different design. Likewise it wouldn’t make much sense to use the truck to do the shopping.

                                In the case of the report, if the requirement to run in a specific limited time would have been known up front, we wouldn’t have wasted time building a report that wasn’t good enough. There are lots of examples I am sure where a certain amount of up-front design work ensures that the final product is fit for the purpose. But that can only take place if the non-functional requirements are captured. So how do you guys go about capturing them, especially of the product backlog does not contain them?

                                Regards,

                                 

                                Wolfgang


                                From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Ron Jeffries
                                Sent: 03 May 2006 20:37
                                To: scrumdevelopment@yahoogroups.com
                                Subject: Re: [scrumdevelopment] Re: Non-functional requirements

                                 

                                On Wednesday, May 3, 2006, at 2:00:03 PM, David A Barrett wrote:

                                > Saying [sayonara] to discussions of this nature is one of the key
                                > benefits of Scrum, in my opinion.

                                Yes. To all the agile methods I know, in fact ...

                                > I can't see where it matters whether the slow performance is bug.
                                > Making the report run faster is going to take time, and that time
                                > won't be available to do other things. So, even if it is a bug,
                                > I'd still put it in the PB and let the PO decide if it's worth
                                > fixing or not. End of discussion.

                                Exactly. The software isn't doing what we want. PO decides whether
                                to spend on it or not. End of discussion. Marvelously elegant.

                                > In the old waterfall world, we used to get into this debate all
                                > the time. Why? Because there was an implied agreement that
                                > anything that was a bug was the development team's responsibility
                                > to fix without impacting the delivery schedule. The only way that
                                > the team could get extra time to change it was convince everyone
                                > that it was an enhancement. The users, on the other hand, wanted
                                > everything to be a bug (or some deviation from the agreed upon
                                > requirements) so that they could get it without paying a time (or
                                > cost) penalty.

                                Yes. Which is absurd on the face of it, as if time could somehow be
                                created. Do you want it fixed, or not, that's the question. If you
                                do, what are you going to take off the table?

                                Ron Jeffries
                                www.XProgramming.com
                                We know less about the project today than at any time in the future.
                                  -- Chet Hendrickson
                                You mean today is the dumbest day of the rest of my life?
                                  -- Ron Jeffries




                              • Ron Jeffries
                                ... Well, Wolfgang, whatever you re doing, it s not Scrum as I know it. As for test tools, why have you decided not to get any? Why have you decided not to
                                Message 15 of 18 , May 4, 2006
                                • 0 Attachment
                                  On Thursday, May 4, 2006, at 11:23:19 AM, Wolfgang Schulze Zachau wrote:

                                  > I am sorry guys, but this is not where I am. I don’t have a QA team. I don’t
                                  > have any fancy test tools that would allow me to set up tests that measure
                                  > non-functional performance criteria (and I won’t get them, either). Most of
                                  > all, I don’t have a customer that will specify acceptance criteria for his
                                  > stories. Which is exactly why I brought up the subject in the first place!

                                  Well, Wolfgang, whatever you're doing, it's not Scrum as I know it.
                                  As for test tools, why have you decided not to get any? Why have you
                                  decided not to dedicate any of your efforts to making things work to
                                  your, and the bosses, satisfaction?

                                  I'm having trouble understanding what you're looking for. What kind
                                  of advice would you like to hear, that you would follow?

                                  > I have to deal with product backlog items such as “Fix queries to Bob’s
                                  > satisfaction”, and when Bob is asked to tell us what that means, he says he
                                  > isn’t quite sure and it won’t be that big and he really needs this to be
                                  > done in the next sprint and because Bob is the boss, the team says “OK,
                                  > we’ll do it”.

                                  Just what is your job on this team?

                                  > I then ask the team how they are going to estimate this and they say they
                                  > trust Bob and therefore it’s this and that size. The actual requirements
                                  > never get written down anywhere and when the whole thing comes up again in
                                  > the sprint review, the team is pretty much at Bob’s mercy. If Bob was
                                  > available during the sprint, then chances are the team could quiz him and
                                  > they get it right. If Bob wasn’t available, well, take your guess.

                                  > So once again, the question here: how do you elicit this important
                                  > information from your customer ?

                                  If teams are doing what Scrum and the other Agile methods teach,
                                  this drops out more or less automatically. If the customer mentions
                                  performance the first time around, it's taken into account. If he
                                  mentions it later, it's taken into account then, and he learns what
                                  the value is of mentioning it sooner. (If there is any value: I'm
                                  not convinced that there is.)

                                  But it sounds to me as if you don't have a Product Owner who
                                  communicates your priorities in any useful way; your team doesn't
                                  provide any useful estimates of what is to be done; the PO and team
                                  don't talk with each other regularly; and there's not much testing
                                  going on.

                                  If that's not accurate, then tell us a bit more about how you're
                                  doing Scrum at your place.

                                  Thanks,

                                  Ron Jeffries
                                  www.XProgramming.com
                                  Perhaps this Silver Bullet will tell you who I am ...
                                • David A Barrett
                                  ... First, I tried to just let this one slip by....... Couldn t do it. Sorry... Do you want to know how to set up the perfect condition for a quick fix ? Use
                                  Message 16 of 18 , May 4, 2006
                                  • 0 Attachment
                                    >With all the benefits that it brings, SCRUM also introduces a tendency
                                    >towards "quick fixes".

                                    First, I tried to just let this one slip by.......

                                    Couldn't do it.

                                    Sorry...

                                    Do you want to know how to set up the perfect condition for a "quick fix"?

                                    Use waterfall. Define a system down to the tiniest detail that anyone can
                                    think of. Spend 6 months writing specifications, DFD's and data models.
                                    Draw hundreds of Gantt charts and modify them religiously every week.
                                    Program for months without letting the users see what you've done.
                                    Suddenly ask for an extension 6 weeks from the end of 18 month project.

                                    And through all of that, miss a non-functional specification like execution
                                    speed under a real-life load. Discover it 2 weeks before your "go live"
                                    date, after you've already delayed the project 3 times.

                                    Then sit back and watch your developers implement a quick fix!


                                    There's a world of difference between "Just good enough" and "Quick fix".
                                    Scrum is iterative, incremental development; not successive "quick fixes".



                                    Dave Barrett,
                                    Lawyers' Professional Indemnity Company
                                  • Jeff Heinen
                                    What is his response when a team member asks for clarification about a backlog? ________________________________ From: scrumdevelopment@yahoogroups.com
                                    Message 17 of 18 , May 4, 2006
                                    • 0 Attachment
                                      What is his response when a team member asks for clarification about a backlog?


                                      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Wolfgang Schulze Zachau
                                      Sent: Thursday, May 04, 2006 9:48 AM
                                      To: scrumdevelopment@yahoogroups.com
                                      Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                                      Bob does participate in the sprint planning meeting.

                                       

                                      Regards,

                                       

                                      Wolfgang


                                      From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Jeff Heinen
                                      Sent: 04 May 2006 17:22
                                      To: scrumdevelopment@yahoogroups.com
                                      Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                                       

                                      Does Bob participate in the sprint planning meeting, or does he just write backlog items and let the team take it from there?

                                       


                                      From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Wolfgang Schulze Zachau
                                      Sent: Thursday, May 04, 2006 8:23 AM
                                      To:scrumdevelopment@yahoogroups.com
                                      Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                                      I am sorry guys, but this is not where I am. I don’t have a QA team. I don’t have any fancy test tools that would allow me to set up tests that measure non-functional performance criteria (and I won’t get them, either). Most of all, I don’t have a customer that will specify acceptance criteria for his stories. Which is exactly why I brought up the subject in the first place!

                                      I have to deal with product backlog items such as “Fix queries to Bob’s satisfaction”, and when Bob is asked to tell us what that means, he says he isn’t quite sure and it won’t be that big and he really needs this to be done in the next sprint and because Bob is the boss, the team says “OK, we’ll do it”.

                                      I then ask the team how they are going to estimate this and they say they trust Bob and therefore it’s this and that size. The actual requirements never get written down anywhere and when the whole thing comes up again in the sprint review, the team is pretty much at Bob’s mercy. If Bob was available during the sprint, then chances are the team could quiz him and they get it right. If Bob wasn’t available, well, take your guess.

                                       

                                      So once again, the question here: how do you elicit this important information from your customer ?

                                      Regards,

                                       

                                      Wolfgang


                                      From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Pascal Roy
                                      Sent: 04 May 2006 15:25
                                      To: scrumdevelopment@yahoogroups.com
                                      Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                                       

                                      When the customer writes a user story that goes into a sprint, he also specifies the criteria for accepting the said story. A performance criteria can be one of many criteria, usability might be another although that would be harder to automate. QA people typically help the customer define those criteria and very often work along with developers on automating tests that check all the criteria. These tests constitute a very valuable asset because they specify what the customer really wants in a non ambiguous form.  The beauty of automated tests is that they can’t be misinterpreted, they either work or don’t. Of course, automating all these criteria into tests is a lot of really hard work (right now, the tools available are very brittle and fairly difficult to learn). Even just thinking about the criteria is a lot of work but hey, somebody shouldn’t actually have an idea of how the software ought to behave before we actually start building it?.  

                                       

                                      Ideally, as developers, the best thing for us would be to have the automated acceptance tests available up front so we have a clear and testable target to continually check that the code we write actually meets the acceptance criteria. In practice, this is really hard to do, but it’s doable if the team commits to it…  

                                       

                                      Pascal Roy, ing./P.Eng., PMP

                                      Vice-Président/Vice President

                                      Elapse Technologies Inc.

                                       

                                      [url]    http://www.elapsetech.com

                                      [email]  pascal.roy@...

                                      [cell]   514-862-6836

                                       

                                       


                                      From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Wolfgang Schulze Zachau
                                      Sent: 4 mai 2006 04:10
                                      To: scrumdevelopment@yahoogroups.com
                                      Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                                       

                                      This isn’t about bug or not, this is about non-functional requirements, i.e. parameters to an application that determine the environment or performance, such as “can be run by 50 people simultaneously without impact

                                      on the performance”, “can process 2000 orders per day”, “is suitable for visually impaired people” (what is the definition of “suitable” ?).

                                      With all the benefits that it brings, SCRUM also introduces a tendency towards “quick fixes”. If the product owner starts a new product by building a prototype that is just good enough to run on one desktop PC for one user, etc. and none of the non-functional requirements are defined, then rolling out that application into usage for 20 or 200 or 2000 users will most likely end up in disaster.

                                      This is a bit like using the right kind of vehicle for transporting goods. If one goes shopping for a family, a small car might be enough. If one is about to deliver 20 tons of groceries to a supermarket, a big truck is needed. And no matter what efforts are made, a small family car cannot be converted into a big truck. It is a fundamentally different design. Likewise it wouldn’t make much sense to use the truck to do the shopping.

                                      In the case of the report, if the requirement to run in a specific limited time would have been known up front, we wouldn’t have wasted time building a report that wasn’t good enough. There are lots of examples I am sure where a certain amount of up-front design work ensures that the final product is fit for the purpose. But that can only take place if the non-functional requirements are captured. So how do you guys go about capturing them, especially of the product backlog does not contain them?

                                      Regards,

                                       

                                      Wolfgang


                                      From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Ron Jeffries
                                      Sent: 03 May 2006 20:37
                                      To: scrumdevelopment@yahoogroups.com
                                      Subject: Re: [scrumdevelopment] Re: Non-functional requirements

                                       

                                      On Wednesday, May 3, 2006, at 2:00:03 PM, David A Barrett wrote:

                                      > Saying [sayonara] to discussions of this nature is one of the key
                                      > benefits of Scrum, in my opinion.

                                      Yes. To all the agile methods I know, in fact ...

                                      > I can't see where it matters whether the slow performance is bug.
                                      > Making the report run faster is going to take time, and that time
                                      > won't be available to do other things. So, even if it is a bug,
                                      > I'd still put it in the PB and let the PO decide if it's worth
                                      > fixing or not. End of discussion.

                                      Exactly. The software isn't doing what we want. PO decides whether
                                      to spend on it or not. End of discussion. Marvelously elegant.

                                      > In the old waterfall world, we used to get into this debate all
                                      > the time. Why? Because there was an implied agreement that
                                      > anything that was a bug was the development team's responsibility
                                      > to fix without impacting the delivery schedule. The only way that
                                      > the team could get extra time to change it was convince everyone
                                      > that it was an enhancement. The users, on the other hand, wanted
                                      > everything to be a bug (or some deviation from the agreed upon
                                      > requirements) so that they could get it without paying a time (or
                                      > cost) penalty.

                                      Yes. Which is absurd on the face of it, as if time could somehow be
                                      created. Do you want it fixed, or not, that's the question. If you
                                      do, what are you going to take off the table?

                                      Ron Jeffries
                                      www.XProgramming.com
                                      We know less about the project today than at any time in the future.
                                        -- Chet Hendrickson
                                      You mean today is the dumbest day of the rest of my life?
                                        -- Ron Jeffries




                                    • Wolfgang Schulze Zachau
                                      His responses vary from providing the information requested to “let’s press on, we don’t have time for this right now.” Regards, Wolfgang _____ From:
                                      Message 18 of 18 , May 5, 2006
                                      • 0 Attachment

                                        His responses vary from providing the information requested to “let’s press on, we don’t have time for this right now.”

                                         

                                        Regards,

                                         

                                        Wolfgang


                                        From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Jeff Heinen
                                        Sent: 04 May 2006 21:39
                                        To: scrumdevelopment@yahoogroups.com
                                        Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                                         

                                        What is his response when a team member asks for clarification about a backlog?

                                         


                                        From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Wolfgang Schulze Zachau
                                        Sent: Thursday, May 04, 2006 9:48 AM
                                        To: scrumdevelopment@yahoogroups.com
                                        Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                                        Bob does participate in the sprint planning meeting.

                                         

                                        Regards,

                                         

                                        Wolfgang


                                        From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Jeff Heinen
                                        Sent: 04 May 2006 17:22
                                        To: scrumdevelopment@yahoogroups.com
                                        Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                                         

                                        Does Bob participate in the sprint planning meeting, or does he just write backlog items and let the team take it from there?

                                         


                                        From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Wolfgang Schulze Zachau
                                        Sent: Thursday, May 04, 2006 8:23 AM
                                        To: scrumdevelopment@yahoogroups.com
                                        Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                                        I am sorry guys, but this is not where I am. I don’t have a QA team. I don’t have any fancy test tools that would allow me to set up tests that measure non-functional performance criteria (and I won’t get them, either). Most of all, I don’t have a customer that will specify acceptance criteria for his stories. Which is exactly why I brought up the subject in the first place!

                                        I have to deal with product backlog items such as “Fix queries to Bob’s satisfaction”, and when Bob is asked to tell us what that means, he says he isn’t quite sure and it won’t be that big and he really needs this to be done in the next sprint and because Bob is the boss, the team says “OK, we’ll do it”.

                                        I then ask the team how they are going to estimate this and they say they trust Bob and therefore it’s this and that size. The actual requirements never get written down anywhere and when the whole thing comes up again in the sprint review, the team is pretty much at Bob’s mercy. If Bob was available during the sprint, then chances are the team could quiz him and they get it right. If Bob wasn’t available, well, take your guess.

                                         

                                        So once again, the question here: how do you elicit this important information from your customer ?

                                        Regards,

                                         

                                        Wolfgang


                                        From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Pascal Roy
                                        Sent: 04 May 2006 15:25
                                        To: scrumdevelopment@yahoogroups.com
                                        Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                                         

                                        When the customer writes a user story that goes into a sprint, he also specifies the criteria for accepting the said story. A performance criteria can be one of many criteria, usability might be another although that would be harder to automate. QA people typically help the customer define those criteria and very often work along with developers on automating tests that check all the criteria. These tests constitute a very valuable asset because they specify what the customer really wants in a non ambiguous form.  The beauty of automated tests is that they can’t be misinterpreted, they either work or don’t. Of course, automating all these criteria into tests is a lot of really hard work (right now, the tools available are very brittle and fairly difficult to learn). Even just thinking about the criteria is a lot of work but hey, somebody shouldn’t actually have an idea of how the software ought to behave before we actually start building it?.  

                                         

                                        Ideally, as developers, the best thing for us would be to have the automated acceptance tests available up front so we have a clear and testable target to continually check that the code we write actually meets the acceptance criteria. In practice, this is really hard to do, but it’s doable if the team commits to it…  

                                         

                                        Pascal Roy, ing./P.Eng., PMP

                                        Vice-Président/Vice President

                                        Elapse Technologies Inc.

                                         

                                        [url]    http://www.elapsetech.com

                                        [email]  pascal.roy@...

                                        [cell]   514-862-6836

                                         

                                         


                                        From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Wolfgang Schulze Zachau
                                        Sent: 4 mai 2006 04:10
                                        To: scrumdevelopment@yahoogroups.com
                                        Subject: RE: [scrumdevelopment] Re: Non-functional requirements

                                         

                                        This isn’t about bug or not, this is about non-functional requirements, i.e. parameters to an application that determine the environment or performance, such as “can be run by 50 people simultaneously without impact

                                        on the performance”, “can process 2000 orders per day”, “is suitable for visually impaired people” (what is the definition of “suitable” ?).

                                        With all the benefits that it brings, SCRUM also introduces a tendency towards “quick fixes”. If the product owner starts a new product by building a prototype that is just good enough to run on one desktop PC for one user, etc. and none of the non-functional requirements are defined, then rolling out that application into usage for 20 or 200 or 2000 users will most likely end up in disaster.

                                        This is a bit like using the right kind of vehicle for transporting goods. If one goes shopping for a family, a small car might be enough. If one is about to deliver 20 tons of groceries to a supermarket, a big truck is needed. And no matter what efforts are made, a small family car cannot be converted into a big truck. It is a fundamentally different design. Likewise it wouldn’t make much sense to use the truck to do the shopping.

                                        In the case of the report, if the requirement to run in a specific limited time would have been known up front, we wouldn’t have wasted time building a report that wasn’t good enough. There are lots of examples I am sure where a certain amount of up-front design work ensures that the final product is fit for the purpose. But that can only take place if the non-functional requirements are captured. So how do you guys go about capturing them, especially of the product backlog does not contain them?

                                        Regards,

                                         

                                        Wolfgang


                                        From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Ron Jeffries
                                        Sent: 03 May 2006 20:37
                                        To: scrumdevelopment@yahoogroups.com
                                        Subject: Re: [scrumdevelopment] Re: Non-functional requirements

                                         

                                        On Wednesday, May 3, 2006, at 2:00:03 PM, David A Barrett wrote:

                                        > Saying [sayonara] to discussions of this nature is one of the key
                                        > benefits of Scrum, in my opinion.

                                        Yes. To all the agile methods I know, in fact ...

                                        > I can't see where it matters whether the slow performance is bug.
                                        > Making the report run faster is going to take time, and that time
                                        > won't be available to do other things. So, even if it is a bug,
                                        > I'd still put it in the PB and let the PO decide if it's worth
                                        > fixing or not. End of discussion.

                                        Exactly. The software isn't doing what we want. PO decides whether
                                        to spend on it or not. End of discussion. Marvelously elegant.

                                        > In the old waterfall world, we used to get into this debate all
                                        > the time. Why? Because there was an implied agreement that
                                        > anything that was a bug was the development team's responsibility
                                        > to fix without impacting the delivery schedule. The only way that
                                        > the team could get extra time to change it was convince everyone
                                        > that it was an enhancement. The users, on the other hand, wanted
                                        > everything to be a bug (or some deviation from the agreed upon
                                        > requirements) so that they could get it without paying a time (or
                                        > cost) penalty.

                                        Yes. Which is absurd on the face of it, as if time could somehow be
                                        created. Do you want it fixed, or not, that's the question. If you
                                        do, what are you going to take off the table?

                                        Ron Jeffries
                                        www.XProgramming.com
                                        We know less about the project today than at any time in the future.
                                          -- Chet Hendrickson
                                        You mean today is the dumbest day of the rest of my life?
                                          -- Ron Jeffries


                                         


                                      Your message has been successfully submitted and would be delivered to recipients shortly.