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

inclusion of complex requirements

Expand Messages
  • francisco.mardones
    Hi, I ve been succesfully using Scrum in traditional projects (like create a new web app where tipical requirements are create a login page or send a
    Message 1 of 6 , Jul 3, 2009
    • 0 Attachment
      Hi,

      I've been succesfully using Scrum in "traditional" projects (like "create a new web app" where tipical requirements are "create a login page" or "send a confirmation message via email once registered"). However, I'm trying now to use it in more complex projects and I'm facing problems to split non-trivial requirements. 

      For instance, we have to send messages to a supervisor (via email or SMS, is not relevant) when an employee inside a mining facility exceed certain speed (for instance when is running inside the facility or is moving in a vehicle). The way to compute his speed is trilaterating radio signals from a radio-scouting system in the helmet. We have found this is not trivial to develop, since requires to write an algorithm to convert radio round trip delays to speeds, measure accuracy, etc. A lot to do before just simply send the message.

      So, we cannot just include the feature "send a message to supervisor when an operator runs" into our 2 weeks sprint, since probably the research will take more than that. What do you do when have complex requirements like this one?. My initial thought was split this feature in a waterfall-esque way (analisys, design, code and test) and spread them into sprints, but doesn't look right.

      thoughts?
      Francisco
    • Adam Sroka
      The first thing I would do would be to split send a message to supervisor from determine and display employee s speed . That is the most obvious
      Message 2 of 6 , Jul 3, 2009
      • 0 Attachment
        The first thing I would do would be to split "send a message to
        supervisor" from "determine and display employee's speed". That is the
        most obvious decomposition. If you can calculate the speed you can
        display it on the command line. That is slightly less complex than
        emailing or SMSing it somewhere, and it saves some work.

        Beyond that, I am willing to bet that the process of determining the
        speed can be decomposed to some degree. Since I am not familiar with
        the domain, the hardware, or the APIs you will be using I can't really
        speculate as to how. However, I have seen graphics and networking
        problems that were likely as complex as the one you are facing and
        there was always some way to break them up.

        For example, if you know you are going to use trilateration how
        difficult is it to determine the distance from a single receiver? Can
        you calculate the change in distance over time to get a single
        component of velocity? How many samples do you need?

        I don't know that these are necessarily the questions you need to ask,
        but part of your goal in asking questions should be to find out what
        smaller problems you have to solve in order to solve the big one. As
        long as these smaller problems are something you can code and
        demonstrate as working software they are candidates for stories.

        On Fri, Jul 3, 2009 at 6:04 PM,
        francisco.mardones<francisco.pub@...> wrote:
        >
        >
        > Hi,
        >
        > I've been succesfully using Scrum in "traditional" projects (like "create a
        > new web app" where tipical requirements are "create a login page" or "send a
        > confirmation message via email once registered"). However, I'm trying now to
        > use it in more complex projects and I'm facing problems to split non-trivial
        > requirements.
        > For instance, we have to send messages to a supervisor (via email or SMS, is
        > not relevant) when an employee inside a mining facility exceed certain speed
        > (for instance when is running inside the facility or is moving in a
        > vehicle). The way to compute his speed is trilaterating radio signals from a
        > radio-scouting system in the helmet. We have found this is not trivial to
        > develop, since requires to write an algorithm to convert radio round trip
        > delays to speeds, measure accuracy, etc. A lot to do before just simply send
        > the message.
        > So, we cannot just include the feature "send a message to supervisor when an
        > operator runs" into our 2 weeks sprint, since probably the research will
        > take more than that. What do you do when have complex requirements like this
        > one?. My initial thought was split this feature in a waterfall-esque way
        > (analisys, design, code and test) and spread them into sprints, but doesn't
        > look right.
        > thoughts?
        > Francisco
        >
      • francisco.mardones
        Thanks. Well, separating the message is absolutely a good idea. In general terms (outside the specific problem described), there are tasks that need long
        Message 3 of 6 , Jul 3, 2009
        • 0 Attachment
          Thanks. Well, separating the message is absolutely a good idea. In general terms (outside the specific problem described), there are tasks that need long analysis, so cannot be split in less than 16 hours. How do you manage them? Where you incorporate the research work required to do, before any implementation?

          thanks

          --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
          >
          > The first thing I would do would be to split "send a message to
          > supervisor" from "determine and display employee's speed". That is the
          > most obvious decomposition. If you can calculate the speed you can
          > display it on the command line. That is slightly less complex than
          > emailing or SMSing it somewhere, and it saves some work.
          >
          > Beyond that, I am willing to bet that the process of determining the
          > speed can be decomposed to some degree. Since I am not familiar with
          > the domain, the hardware, or the APIs you will be using I can't really
          > speculate as to how. However, I have seen graphics and networking
          > problems that were likely as complex as the one you are facing and
          > there was always some way to break them up.
          >
          > For example, if you know you are going to use trilateration how
          > difficult is it to determine the distance from a single receiver? Can
          > you calculate the change in distance over time to get a single
          > component of velocity? How many samples do you need?
          >
          > I don't know that these are necessarily the questions you need to ask,
          > but part of your goal in asking questions should be to find out what
          > smaller problems you have to solve in order to solve the big one. As
          > long as these smaller problems are something you can code and
          > demonstrate as working software they are candidates for stories.
          >
          > On Fri, Jul 3, 2009 at 6:04 PM,
          > francisco.mardones<francisco.pub@...> wrote:
          > >
          > >
          > > Hi,
          > >
          > > I've been succesfully using Scrum in "traditional" projects (like "create a
          > > new web app" where tipical requirements are "create a login page" or "send a
          > > confirmation message via email once registered"). However, I'm trying now to
          > > use it in more complex projects and I'm facing problems to split non-trivial
          > > requirements.
          > > For instance, we have to send messages to a supervisor (via email or SMS, is
          > > not relevant) when an employee inside a mining facility exceed certain speed
          > > (for instance when is running inside the facility or is moving in a
          > > vehicle). The way to compute his speed is trilaterating radio signals from a
          > > radio-scouting system in the helmet. We have found this is not trivial to
          > > develop, since requires to write an algorithm to convert radio round trip
          > > delays to speeds, measure accuracy, etc. A lot to do before just simply send
          > > the message.
          > > So, we cannot just include the feature "send a message to supervisor when an
          > > operator runs" into our 2 weeks sprint, since probably the research will
          > > take more than that. What do you do when have complex requirements like this
          > > one?. My initial thought was split this feature in a waterfall-esque way
          > > (analisys, design, code and test) and spread them into sprints, but doesn't
          > > look right.
          > > thoughts?
          > > Francisco
          > >
          >
        • Adam Sroka
          In general Agile prefers working experiments to research. If you can develop something that is part of the solution, or even something that proves the
          Message 4 of 6 , Jul 3, 2009
          • 0 Attachment
            In general Agile prefers working experiments to research. If you can
            develop something that is part of the solution, or even something that
            proves the infeasibility of a particular approach, and you can do so
            with working software, then you are golden.

            What I am suggesting is that you ask yourself what questions would
            need to be answered in order to know that you had a workable solution.
            Once you know what those questions are, for each question how could
            you create some running code that would help you to answer it?

            If the code you will end up creating is purely experimental - it isn't
            likely to be part of the final solution, it might not even be the
            right approach - then you can do what we call a "Spike Solution." Set
            aside a fixed amount of time, generally a day or two, to work on the
            solution. At the end of that time throw away the experimental code and
            use the knowledge you've gained to estimate what you need for a real
            solution.

            On Fri, Jul 3, 2009 at 6:48 PM,
            francisco.mardones<francisco.pub@...> wrote:
            >
            >
            > Thanks. Well, separating the message is absolutely a good idea. In general
            > terms (outside the specific problem described), there are tasks that need
            > long analysis, so cannot be split in less than 16 hours. How do you manage
            > them? Where you incorporate the research work required to do, before any
            > implementation?
            >
            > thanks
            >
            > --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
            >>
            >> The first thing I would do would be to split "send a message to
            >> supervisor" from "determine and display employee's speed". That is the
            >> most obvious decomposition. If you can calculate the speed you can
            >> display it on the command line. That is slightly less complex than
            >> emailing or SMSing it somewhere, and it saves some work.
            >>
            >> Beyond that, I am willing to bet that the process of determining the
            >> speed can be decomposed to some degree. Since I am not familiar with
            >> the domain, the hardware, or the APIs you will be using I can't really
            >> speculate as to how. However, I have seen graphics and networking
            >> problems that were likely as complex as the one you are facing and
            >> there was always some way to break them up.
            >>
            >> For example, if you know you are going to use trilateration how
            >> difficult is it to determine the distance from a single receiver? Can
            >> you calculate the change in distance over time to get a single
            >> component of velocity? How many samples do you need?
            >>
            >> I don't know that these are necessarily the questions you need to ask,
            >> but part of your goal in asking questions should be to find out what
            >> smaller problems you have to solve in order to solve the big one. As
            >> long as these smaller problems are something you can code and
            >> demonstrate as working software they are candidates for stories.
            >>
            >> On Fri, Jul 3, 2009 at 6:04 PM,
            >> francisco.mardones<francisco.pub@...> wrote:
            >> >
            >> >
            >> > Hi,
            >> >
            >> > I've been succesfully using Scrum in "traditional" projects (like
            >> > "create a
            >> > new web app" where tipical requirements are "create a login page" or
            >> > "send a
            >> > confirmation message via email once registered"). However, I'm trying
            >> > now to
            >> > use it in more complex projects and I'm facing problems to split
            >> > non-trivial
            >> > requirements.
            >> > For instance, we have to send messages to a supervisor (via email or
            >> > SMS, is
            >> > not relevant) when an employee inside a mining facility exceed certain
            >> > speed
            >> > (for instance when is running inside the facility or is moving in a
            >> > vehicle). The way to compute his speed is trilaterating radio signals
            >> > from a
            >> > radio-scouting system in the helmet. We have found this is not trivial
            >> > to
            >> > develop, since requires to write an algorithm to convert radio round
            >> > trip
            >> > delays to speeds, measure accuracy, etc. A lot to do before just simply
            >> > send
            >> > the message.
            >> > So, we cannot just include the feature "send a message to supervisor
            >> > when an
            >> > operator runs" into our 2 weeks sprint, since probably the research will
            >> > take more than that. What do you do when have complex requirements like
            >> > this
            >> > one?. My initial thought was split this feature in a waterfall-esque way
            >> > (analisys, design, code and test) and spread them into sprints, but
            >> > doesn't
            >> > look right.
            >> > thoughts?
            >> > Francisco
            >> >
            >>
            >
            >
          • PaulOldfield1@aol.com
            (responding to Francisco) ... This is akin to air traffic control - you can split out the processing of each single sensor message from the integration of all
            Message 5 of 6 , Jul 4, 2009
            • 0 Attachment
              (responding to Francisco)
               
              > For example, if you know you are going to use trilateration
              >
              how difficult is it to determine the distance from a single
              > receiver?
              Can you calculate the change in distance over time
              > to get a single
              component of velocity? How many samples do
              > you need?
               
              This is akin to air traffic control - you can split out the
              processing of each single sensor message from the integration
              of all sensor messages to track individual people / vehicles
              in 3D space (perhaps 2D is sucfficient?).
               
              I have to say at this point, though, that the 3D multisensor
              tracking we did for an Air Traffic Control system is my
              archetypal example (and the only situation I have come across
              in the last 15 years) where I could not split the work small
              enough to fit in a 2 week sprint.  It's the exception that
              proves the rule :-)
               
              Paul Oldfield
              Capgemini

               
            • Michael Vizdos
              I d challenge you to talk to the team and stakeholders and Product Owner about how to decompose the stories into something that has value at the end of each
              Message 6 of 6 , Jul 5, 2009
              • 0 Attachment
                I'd challenge you to talk to the team and stakeholders and Product
                Owner about how to decompose the stories into something that has value
                at the end of each iteration.

                As you'll recall from earlier projects (it sounds like you have
                experience!) remember the goal of each Sprint is not to deliver
                prototypes or documents.

                Another general question for you -- Why do you want to use Scrum on
                this project?

                - mike
                www.michaelvizdos.com
                www.implementingscrum.com

                On Fri, Jul 3, 2009 at 9:04 PM,
                francisco.mardones<francisco.pub@...> wrote:
                >
                >
                > Hi,
                >
                > I've been succesfully using Scrum in "traditional" projects (like "create a
                > new web app" where tipical requirements are "create a login page" or "send a
                > confirmation message via email once registered"). However, I'm trying now to
                > use it in more complex projects and I'm facing problems to split non-trivial
                > requirements.
                > For instance, we have to send messages to a supervisor (via email or SMS, is
                > not relevant) when an employee inside a mining facility exceed certain speed
                > (for instance when is running inside the facility or is moving in a
                > vehicle). The way to compute his speed is trilaterating radio signals from a
                > radio-scouting system in the helmet. We have found this is not trivial to
                > develop, since requires to write an algorithm to convert radio round trip
                > delays to speeds, measure accuracy, etc. A lot to do before just simply send
                > the message.
                > So, we cannot just include the feature "send a message to supervisor when an
                > operator runs" into our 2 weeks sprint, since probably the research will
                > take more than that. What do you do when have complex requirements like this
                > one?. My initial thought was split this feature in a waterfall-esque way
                > (analisys, design, code and test) and spread them into sprints, but doesn't
                > look right.
                > thoughts?
                > Francisco
                >
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.