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

RE: [XP] Get all the requirements early?

Expand Messages
  • Wilson, Michael
    It might mean you ve got to split up your big requirements doc in to a few smaller stories for us to consume more easily ;) ... From:
    Message 1 of 44 , Sep 28, 2007
    • 0 Attachment
      It might mean you've got to split up your big requirements doc in to a
      few smaller stories for us to consume more easily ;)


      -----Original Message-----
      From: extremeprogramming@yahoogroups.com
      [mailto:extremeprogramming@yahoogroups.com] On Behalf Of
      geoffrey_slinker
      Sent: Friday, September 28, 2007 2:50 PM
      To: extremeprogramming@yahoogroups.com
      Subject: Re: [XP] Get all the requirements early?

      So, no response. Does that mean we are tired of the discussion?
      Does it mean that no one wants to talk to someone that just don't get
      it?
      Does it mean I am right! Woohoo! Or is it what it is and it means no one
      has responded!

      Geoff

      >
      > Here is my take on requirements. Requirements are necessary for
      > planning. Planning and requirements are inseparable.
      >
      > Planning is essential to controlling workload, reducing programmer
      > stress, increasing productivity, and keep projects on track.
      > It is important to estimate the cost and time for each requirement,
      > determining its priority, and planning software releases accordingly.
      >
      > Planning must try to create visibility, so everyone involved in the
      > project can really see how far along a project is. This means you need

      > clear milestones, ones that cannot be fudged, and clearly represent
      > progress. Plans must be honest, including all the information you have

      > to date. Plans should make it difficult for anyone to be fooled by
      > reports of progress unrelated to reality.
      >
      > The customer has the right to an overall plan, to know what can be
      > accomplished when and at what cost.
      > The developer has the right to know what is needed, with clear
      > declarations of priority.
      >
      > Planning is to ensure we always work on the most valuable thing
      > possible at any given time. We have to begin development by taking a
      > quick look at everything that might be valuable.
      >
      > The first plan to be made answers the question "Does this project make

      > any sense at all?". If so then invest enough to prepare a plan you
      > have some confidence in. This is the big plan. As you break out the
      > requirements you estimate them. You can only estimate from experience.
      > If you don't have any experience then write a little prototype or find

      > someone who does have experience. The goal is to quickly capture a
      > picture of the WHOLE system.
      >
      > We break up the whole system into sets of requirements that make
      > releases. Take the requirements and break them into smaller pieces
      > that make up the requirement. Estimate each of these smaller pieces
      > and warn the customer of technical risks. Of course we feedback into
      > the system information as it comes available. During development when
      > we learn something new about the speed of doing things this changes
      > the plan.
      >
      > The further ahead we plan the less accurate it will be, so there's
      > little point going into great detail for years into the future.
      > Planning releases for four to six months is reasonable. This is based
      > on a release being a few months, so a couple of releases could be four

      > to six months. Release planning is a business task. Iteration planning

      > is a technical task and programmers need one or two iterations worth
      > of requirements which is around 2 weeks to a month. (Often the
      > argument of requirements is confused by the fact some are talking
      > about the business requirements and some are talking about the
      > technical requirements. I am usually speaking about the business
      > requirements). For the situation you plan as far in advance as
      > possible while watching the cost of keeping the plan up-to-date versus

      > the benefit you get when you know that plans are inherently unstable.
      >
      > (As the requirements are gathered they should not include
      > implementation details)
      >
      > Each requirement captured in the plan represents a concept and not a
      > detailed specification. (However, each requirement is captured.) These

      > requirements are defined by something that provides value to the
      > customer. Developers do not write the requirements, thus it is not a
      > technical task. Estimates for the "size" of the requirement starts as
      > soon as you start gathering the requirements. Remember, estimates are
      > not commitments.
      >
      > The first plan has two main areas of uncertainty: the speed at which
      > the team can deliver completed requirements and the size of the
      > requirements. (But you start with all of the requirements that could
      > be discovered that would make up a release which is four to six months

      > worth of requirements. The uncertainty is based on speed of delivery
      > and size and is not initially based on the idea that the requirements
      > are mostly incorrect or will change for a release).
      >
      > These requirements are divided up into releases and prioritized by the

      > business/customer, not by the developer. The developer points out
      > technical risks and dependencies but does not set the priority. After
      > the one or two releases are planned then the developers step up and
      > plan the iterations. The programmers put estimates on each task of the

      > iteration. Inside the iteration the technical issues are in control
      > and the developers make the decisions. The customer has their input.
      > While planning the iteration the requirement is read and conversations

      > take place as needed.
      >
      > Sincerely,
      > Geoff
      >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > > These ideas come from Beck and Fowler. See Planning Extreme
      > > Programming.
      > > I have taken the word user story and changed it to requirement.
      > > I am curious if people feel it is wrong once they realize that this
      > > comes from others. No plagiarism intended.
      >




      To Post a message, send it to: extremeprogramming@...

      To Unsubscribe, send a blank message to:
      extremeprogramming-unsubscribe@...

      ad-free courtesy of objectmentor.com
      Yahoo! Groups Links



      -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
      This message is for the named person's use only. This communication is for
      informational purposes only and has been obtained from sources believed to
      be reliable, but it is not necessarily complete and its accuracy cannot be
      guaranteed. It is not intended as an offer or solicitation for the purchase
      or sale of any financial instrument or as an official confirmation of any
      transaction. Moreover, this material should not be construed to contain any
      recommendation regarding, or opinion concerning, any security. It may
      contain confidential, proprietary or legally privileged information. No
      confidentiality or privilege is waived or lost by any mistransmission. If
      you receive this message in error, please immediately delete it and all
      copies of it from your system, destroy any hard copies of it and notify the
      sender. You must not, directly or indirectly, use, disclose, distribute,
      print, or copy any part of this message if you are not the intended
      recipient. Any views expressed in this message are those of the individual
      sender, except where the message states otherwise and the sender is
      authorized to state them to be the views of any such entity.

      Securities products and services provided to Canadian investors are offered
      by ITG Canada Corp. (member CIPF and IDA), an affiliate of Investment
      Technology Group, Inc.

      ITG Inc. and/or its affiliates reserves the right to monitor and archive
      all electronic communications through its network.

      ITG Inc. Member NASD, SIPC
      -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
    • Wilson, Michael
      It might mean you ve got to split up your big requirements doc in to a few smaller stories for us to consume more easily ;) ... From:
      Message 44 of 44 , Sep 28, 2007
      • 0 Attachment
        It might mean you've got to split up your big requirements doc in to a
        few smaller stories for us to consume more easily ;)


        -----Original Message-----
        From: extremeprogramming@yahoogroups.com
        [mailto:extremeprogramming@yahoogroups.com] On Behalf Of
        geoffrey_slinker
        Sent: Friday, September 28, 2007 2:50 PM
        To: extremeprogramming@yahoogroups.com
        Subject: Re: [XP] Get all the requirements early?

        So, no response. Does that mean we are tired of the discussion?
        Does it mean that no one wants to talk to someone that just don't get
        it?
        Does it mean I am right! Woohoo! Or is it what it is and it means no one
        has responded!

        Geoff

        >
        > Here is my take on requirements. Requirements are necessary for
        > planning. Planning and requirements are inseparable.
        >
        > Planning is essential to controlling workload, reducing programmer
        > stress, increasing productivity, and keep projects on track.
        > It is important to estimate the cost and time for each requirement,
        > determining its priority, and planning software releases accordingly.
        >
        > Planning must try to create visibility, so everyone involved in the
        > project can really see how far along a project is. This means you need

        > clear milestones, ones that cannot be fudged, and clearly represent
        > progress. Plans must be honest, including all the information you have

        > to date. Plans should make it difficult for anyone to be fooled by
        > reports of progress unrelated to reality.
        >
        > The customer has the right to an overall plan, to know what can be
        > accomplished when and at what cost.
        > The developer has the right to know what is needed, with clear
        > declarations of priority.
        >
        > Planning is to ensure we always work on the most valuable thing
        > possible at any given time. We have to begin development by taking a
        > quick look at everything that might be valuable.
        >
        > The first plan to be made answers the question "Does this project make

        > any sense at all?". If so then invest enough to prepare a plan you
        > have some confidence in. This is the big plan. As you break out the
        > requirements you estimate them. You can only estimate from experience.
        > If you don't have any experience then write a little prototype or find

        > someone who does have experience. The goal is to quickly capture a
        > picture of the WHOLE system.
        >
        > We break up the whole system into sets of requirements that make
        > releases. Take the requirements and break them into smaller pieces
        > that make up the requirement. Estimate each of these smaller pieces
        > and warn the customer of technical risks. Of course we feedback into
        > the system information as it comes available. During development when
        > we learn something new about the speed of doing things this changes
        > the plan.
        >
        > The further ahead we plan the less accurate it will be, so there's
        > little point going into great detail for years into the future.
        > Planning releases for four to six months is reasonable. This is based
        > on a release being a few months, so a couple of releases could be four

        > to six months. Release planning is a business task. Iteration planning

        > is a technical task and programmers need one or two iterations worth
        > of requirements which is around 2 weeks to a month. (Often the
        > argument of requirements is confused by the fact some are talking
        > about the business requirements and some are talking about the
        > technical requirements. I am usually speaking about the business
        > requirements). For the situation you plan as far in advance as
        > possible while watching the cost of keeping the plan up-to-date versus

        > the benefit you get when you know that plans are inherently unstable.
        >
        > (As the requirements are gathered they should not include
        > implementation details)
        >
        > Each requirement captured in the plan represents a concept and not a
        > detailed specification. (However, each requirement is captured.) These

        > requirements are defined by something that provides value to the
        > customer. Developers do not write the requirements, thus it is not a
        > technical task. Estimates for the "size" of the requirement starts as
        > soon as you start gathering the requirements. Remember, estimates are
        > not commitments.
        >
        > The first plan has two main areas of uncertainty: the speed at which
        > the team can deliver completed requirements and the size of the
        > requirements. (But you start with all of the requirements that could
        > be discovered that would make up a release which is four to six months

        > worth of requirements. The uncertainty is based on speed of delivery
        > and size and is not initially based on the idea that the requirements
        > are mostly incorrect or will change for a release).
        >
        > These requirements are divided up into releases and prioritized by the

        > business/customer, not by the developer. The developer points out
        > technical risks and dependencies but does not set the priority. After
        > the one or two releases are planned then the developers step up and
        > plan the iterations. The programmers put estimates on each task of the

        > iteration. Inside the iteration the technical issues are in control
        > and the developers make the decisions. The customer has their input.
        > While planning the iteration the requirement is read and conversations

        > take place as needed.
        >
        > Sincerely,
        > Geoff
        >
        > >
        > >
        > >
        > >
        > >
        > >
        > >
        > > These ideas come from Beck and Fowler. See Planning Extreme
        > > Programming.
        > > I have taken the word user story and changed it to requirement.
        > > I am curious if people feel it is wrong once they realize that this
        > > comes from others. No plagiarism intended.
        >




        To Post a message, send it to: extremeprogramming@...

        To Unsubscribe, send a blank message to:
        extremeprogramming-unsubscribe@...

        ad-free courtesy of objectmentor.com
        Yahoo! Groups Links



        -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
        This message is for the named person's use only. This communication is for
        informational purposes only and has been obtained from sources believed to
        be reliable, but it is not necessarily complete and its accuracy cannot be
        guaranteed. It is not intended as an offer or solicitation for the purchase
        or sale of any financial instrument or as an official confirmation of any
        transaction. Moreover, this material should not be construed to contain any
        recommendation regarding, or opinion concerning, any security. It may
        contain confidential, proprietary or legally privileged information. No
        confidentiality or privilege is waived or lost by any mistransmission. If
        you receive this message in error, please immediately delete it and all
        copies of it from your system, destroy any hard copies of it and notify the
        sender. You must not, directly or indirectly, use, disclose, distribute,
        print, or copy any part of this message if you are not the intended
        recipient. Any views expressed in this message are those of the individual
        sender, except where the message states otherwise and the sender is
        authorized to state them to be the views of any such entity.

        Securities products and services provided to Canadian investors are offered
        by ITG Canada Corp. (member CIPF and IDA), an affiliate of Investment
        Technology Group, Inc.

        ITG Inc. and/or its affiliates reserves the right to monitor and archive
        all electronic communications through its network.

        ITG Inc. Member NASD, SIPC
        -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
      Your message has been successfully submitted and would be delivered to recipients shortly.