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

How to get from Use-Cases to a Product Backlog?

Expand Messages
  • s_spitaler
    Hi! We re going to use Scrum for Software-Development. By now we used no clear model - it was more a build&fix-cycle way of developing software. But what we
    Message 1 of 7 , Aug 30 10:56 PM
      Hi!

      We're going to use Scrum for Software-Development. By now we used no
      clear model - it was more a "build&fix-cycle" way of developing
      software. But what we do is, that we use use-cases for gathering the
      user-requirements - with which we made good experience. My question:
      Has anybody an advice what a good way to integrate use-cases in to the
      product backlog. any idea is welcome!

      thank you!

      stefan spitaler
      innsbruck
      tirol - austria
    • Vickydhiman
      Hi Tirol: Do you capture ALL the use-cases in Sprint 0 ? We work with SCRUM and Use-Cases. However, we do the reverse. We first make the product backlog.
      Message 2 of 7 , Aug 30 11:07 PM
        Hi Tirol:

        Do you capture "ALL" the use-cases in Sprint "0"?

        We work with SCRUM and Use-Cases. However, we do the reverse. We first make the product backlog. There are some basic specifications [graphical Visio diagrams] + some short sentences at this stage.

        Then, we start with Sprint "0" which has client sign-off on Use-Cases/ Test Cases for first sprint.  During the second sprint - the developers work on the actual value while the Product Owner works with Analysts to write the Use-Cases for the next sprint. Each use -case must relate to to the Product Catalog Item Number.

        Thanks

        Vicki

        s_spitaler <stefan.spitaler@...> wrote:
        Hi!

        We're going to use Scrum for Software-Developmen t. By now we used no
        clear model - it was more a "build&fix-cycle" way of developing
        software. But what we do is, that we use use-cases for gathering the
        user-requirements - with which we made good experience. My question:
        Has anybody an advice what a good way to integrate use-cases in to the
        product backlog. any idea is welcome!

        thank you!

        stefan spitaler
        innsbruck
        tirol - austria



        Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1ยข/min.

      • PaulOldfield1@aol.com
        (responding to Stefan) ... Some ideas you may want to consider... First, don t treat the Use Cases as the requirements , treat them as something that gives
        Message 3 of 7 , Aug 31 2:42 AM
          (responding to Stefan)
           
          > We're going to use Scrum for Software-Development. By
          > now we used no clear model - it was more a "build&fix-
          > cycle" way of developing software. But what we do is, that
          > we use use-cases for gathering the user-requirements -
          > with which we made good experience. My question:
          > Has
          anybody an advice what a good way to integrate
          > use-cases in to the product backlog. any idea is welcome!
           
          Some ideas you may want to consider...
           
          First, don't treat the Use Cases as the "requirements", treat
          them as something that gives structure to the real
          requirements that will be uncovered during the iteration
          and captured ideally as tests.  Coming into the iteration,
          you want to have the use cases good enough to identify
          the scope of what you're doing; good enough to support
          a conversation that will allow the estimation of the work
          to be done in the iteration.  Anything more is premature
          and probably wasted effort.
           
          Second, split the use cases by flow, and do the high-value
          flows in earlier iterations.
           
          Third, if you need even smaller granularity then there are
          possible ways forward, but either of the two I will mention
          has some problems.  You could split the use case into
          flow steps - but this doesn't always deliver value at the end
          of the itaeration.  You could split a flow into scenarios -
          but this doesn't often remove much work.
          Hope this helps,
          Paul Oldfield
        • Kane Mar
          ... first make the product backlog. There are some basic specifications [graphical Visio diagrams] + some short sentences at this stage. ... Use-Cases/ Test
          Message 4 of 7 , Aug 31 4:13 PM
            --- In scrumdevelopment@yahoogroups.com, Vickydhiman <vickydhiman@...>
            wrote:

            > Do you capture "ALL" the use-cases in Sprint "0"?
            >
            > We work with SCRUM and Use-Cases. However, we do the reverse. We
            first make the product backlog. There are some basic specifications
            [graphical Visio diagrams] + some short sentences at this stage.
            >
            > Then, we start with Sprint "0" which has client sign-off on
            Use-Cases/ Test Cases for first sprint. During the second sprint -
            the developers work on the actual value while the Product Owner works
            with Analysts to write the Use-Cases for the next sprint.

            So would I be correct in assuming that the PO and Analysts work one
            Sprint ahead of the development team? How about testing? Do you do the
            testing one sprint behind the developers?

            Best regards,
            Kane Mar
            W: http://www.Danube.com
            B: http://KaneMar.Wordpress.com
            G: http://www.frappr.com/scrumtrainers
          • Vickydhiman
            Hello Kane: Business Analysts have twin responsibilities or three responsibilities in the Sprints: 1. Work with Product Owner and Customer for next Sprint Use
            Message 5 of 7 , Aug 31 9:49 PM
              Hello Kane:

              Business Analysts have twin responsibilities or three responsibilities in the Sprints:
              1. Work with Product Owner and Customer for next Sprint Use Cases
              2. Work with the team to refine and discuss use cases [and write any that are missing that were not thought before]
              3. Work with QA to define acceptance tests for next Sprint

              QA for the sprint is done within the sprint. At the end working software is delivered - tested and accepted.

              Thanks

              Vicki

              Kane Mar <kane_sfo@...> wrote:
              --- In scrumdevelopment@ yahoogroups. com, Vickydhiman <vickydhiman@ ...>
              wrote:

              > Do you capture "ALL" the use-cases in Sprint "0"?
              >
              > We work with SCRUM and Use-Cases. However, we do the reverse. We
              first make the product backlog. There are some basic specifications
              [graphical Visio diagrams] + some short sentences at this stage.
              >
              > Then, we start with Sprint "0" which has client sign-off on
              Use-Cases/ Test Cases for first sprint. During the second sprint -
              the developers work on the actual value while the Product Owner works
              with Analysts to write the Use-Cases for the next sprint.

              So would I be correct in assuming that the PO and Analysts work one
              Sprint ahead of the development team? How about testing? Do you do the
              testing one sprint behind the developers?

              Best regards,
              Kane Mar
              W: http://www.Danube. com
              B: http://KaneMar. Wordpress. com
              G: http://www.frappr. com/scrumtrainer s



              All-new Yahoo! Mail - Fire up a more powerful email and get things done faster.

            • stefan.spitaler@hypotirol.com
              Hi Paul & hi Vicki, thank you very much for your input. I like both of your ideas 1. of using the use-cases to give a structure to the real requirements an
              Message 6 of 7 , Aug 31 11:15 PM

                Hi Paul & hi Vicki,

                thank you very much for your input.
                I like both of your ideas
                1. of using the use-cases to give "a structure to the real requirements" an
                2. having first a product backlog und then make detailed use-cases during the sprint

                do you think it would be a good way do it like that:
                1. make some very rough use cases to get a structure for the product catalog and
                2. go in depth with this use cases during the iteration of the first sprints

                i am aware, that use-cases do not cover all requirements, so e.g. the unfunctional requirements.

                as there are no clear practices given in the books about scrum (or i have not found them) - can you tell me, what is the typical approuch to get the items of the product catalog. is it just making an interview with the potential users/product owner and then write down their "wishes"?

                best regards!

                stefan
              • PaulOldfield1@aol.com
                (responding to Stefan) ... The two best resources to learn about this area, IMO, are both books written by Mike Cohn: Agile Estimating and Planning will
                Message 7 of 7 , Sep 1, 2006
                  (responding to Stefan)
                   
                  > as there are no clear practices given in the books about
                  > scrum (or i have not found them) - can you tell me, what
                  > is the typical approuch to get the items of the product
                  > catalog. is it just making an interview with the potential
                  > users/product owner and then write down their "wishes"?
                   
                  The two best resources to learn about this area, IMO, are
                  both books written by Mike Cohn:
                   
                  "Agile Estimating and Planning" will probably be better at
                  getting you thinking the right way about Product Backlog.
                   
                  "User Stories Applied" will probably be better at giving
                  practical advice on capturing and organising the requirements.
                   
                  There's a third book I often recommend to the more traditional
                  or RUP oriented teams - "Requirements by Collaboration"
                  by Ellen Gottesdiener.  There's a lot of useful stuff in it for
                  folk transitioning from traditional and needing to find better ways
                  of eliciting requirements from customers, but IMHO it stops a
                  bit too far short of full-on agile.
                  Paul Oldfield
                Your message has been successfully submitted and would be delivered to recipients shortly.