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

Prioritization of Stories in Business Productivity Automation

Expand Messages
  • Tara Santmire
    I am the Scrum Master on a software development project building a web portal and automating a set of business processes. We are at the very beginning of the
    Message 1 of 28 , May 31, 2010
    • 0 Attachment

      I am the Scrum Master on a software development project building a web portal and automating a set of business processes.  We are at  the very beginning of the product/project and are building enough of the product backlog to have work for several sprints.  The product owner has picked a particular business process to automate first (highest business value).  We have identified some high level capabilities (home page, task lists, request lists, friendly nags, reporting, etc.)  that cross business processes and steps within a process and have associated user stories which are identified as high priority.  The rest of the user stories have to do with specific capabilities necessary for the various steps in the business process.  The team has agreed that there are no big technical risks in any of these user stories.  The product owner wants to prioritize these stories in the same order that they occur in the business process.  I don’t see any problems with this, but I have a nagging feeling that I am missing something.  Does this seem like a reasonable way of prioritizing the stories?  Does it have any potential drawbacks?

       

      The entire team is relatively new to Scrum.  PO has never used Scrum, but is very much on board.  The team and I have used Scrum on one previous project, which was successful in that the software is actually in use and the external client has ordered additional work.

       

      Tara E. Santmire, CSM, PMP
      tara@...

       

    • George Dinwiddie
      Tara, ... That /seems/ like a reasonable order, but I suspect that the stories you ve identified may not really be the most functional stories. For example,
      Message 2 of 28 , May 31, 2010
      • 0 Attachment
        Tara,

        Tara Santmire wrote:
        >
        >
        > I am the Scrum Master on a software development project building a web
        > portal and automating a set of business processes. We are at the very
        > beginning of the product/project and are building enough of the product
        > backlog to have work for several sprints. The product owner has picked
        > a particular business process to automate first (highest business
        > value). We have identified some high level capabilities (home page,
        > task lists, request lists, friendly nags, reporting, etc.) that cross
        > business processes and steps within a process and have associated user
        > stories which are identified as high priority. The rest of the user
        > stories have to do with specific capabilities necessary for the various
        > steps in the business process. The team has agreed that there are no
        > big technical risks in any of these user stories. The product owner
        > wants to prioritize these stories in the same order that they occur in
        > the business process. I don’t see any problems with this, but I have a
        > nagging feeling that I am missing something. Does this seem like a
        > reasonable way of prioritizing the stories? Does it have any potential
        > drawbacks?

        That /seems/ like a reasonable order, but I suspect that the stories
        you've identified may not really be the most functional stories. For
        example, what sort of story is "home page?"

        I would suggest slicing things differently. Make the first slice the
        /entire/ business process, for the simplest case you can imagine and
        with little or no choices along the way. Make it work all the way
        through, but only for that one narrow set of circumstances. Then start
        to flesh it out for choosing other circumstances.

        I think you'll find this an easier route, and you'll generate a better
        app, if you approach it this way. It's just a simple trick of the mind
        to envision it this way rather than the steps of the business process.

        Please report back how things go for you.

        - George

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      • Tara Santmire
        George - Thanks for taking the time to reply. I like the concept of taking the simplest path through the process first. My guess is that the PO will want to do
        Message 3 of 28 , May 31, 2010
        • 0 Attachment
          George - Thanks for taking the time to reply.

          I like the concept of taking the simplest path through the process first.
          My guess is that the PO will want to do the most likely case first as that
          has more business value. That could still be a valuable prioritization. At
          each choice point say which is more likely and go down that path. Gets you
          one way through the entire process.

          Tara E. Santmire, CSM, PMP
          tara@...


          -----Original Message-----
          From: scrumdevelopment@yahoogroups.com
          [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of George Dinwiddie
          Sent: Monday, May 31, 2010 1:25 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: Re: [scrumdevelopment] Prioritization of Stories in Business
          Productivity Automation

          Tara,

          Tara Santmire wrote:
          >
          >
          > I am the Scrum Master on a software development project building a web
          > portal and automating a set of business processes. We are at the very
          > beginning of the product/project and are building enough of the product
          > backlog to have work for several sprints. The product owner has picked
          > a particular business process to automate first (highest business
          > value). We have identified some high level capabilities (home page,
          > task lists, request lists, friendly nags, reporting, etc.) that cross
          > business processes and steps within a process and have associated user
          > stories which are identified as high priority. The rest of the user
          > stories have to do with specific capabilities necessary for the various
          > steps in the business process. The team has agreed that there are no
          > big technical risks in any of these user stories. The product owner
          > wants to prioritize these stories in the same order that they occur in
          > the business process. I don't see any problems with this, but I have a
          > nagging feeling that I am missing something. Does this seem like a
          > reasonable way of prioritizing the stories? Does it have any potential
          > drawbacks?

          That /seems/ like a reasonable order, but I suspect that the stories
          you've identified may not really be the most functional stories. For
          example, what sort of story is "home page?"

          I would suggest slicing things differently. Make the first slice the
          /entire/ business process, for the simplest case you can imagine and
          with little or no choices along the way. Make it work all the way
          through, but only for that one narrow set of circumstances. Then start
          to flesh it out for choosing other circumstances.

          I think you'll find this an easier route, and you'll generate a better
          app, if you approach it this way. It's just a simple trick of the mind
          to envision it this way rather than the steps of the business process.

          Please report back how things go for you.

          - George

          --
          ----------------------------------------------------------------------
          * George Dinwiddie * http://blog.gdinwiddie.com
          Software Development http://www.idiacomputing.com
          Consultant and Coach http://www.agilemaryland.org
          ----------------------------------------------------------------------



          ------------------------------------

          To Post a message, send it to: scrumdevelopment@...
          To Unsubscribe, send a blank message to:
          scrumdevelopment-unsubscribe@...! Groups Links
        • Michael James
          Adding to George s response, keep reminding both the Product Owner and development team that the Product Backlog is subject to constant revision and
          Message 4 of 28 , May 31, 2010
          • 0 Attachment
            Adding to George's response, keep reminding both the Product Owner and development team that the Product Backlog is subject to constant revision and reprioritization. Chet Hendrickson wrote "We know less about the project today than at any time in the future." Even though those business processes appear to be locked down at the moment, it's likely that people will think of improvements, clarifications, fall behind schedule, etc. Some of your requirements can probably be split so that 80% of the value is derived from 20% of the effort of the original requirement. An attentive Product Owner is always looking for opportunities to slice and dice so high value work is done first.

            --mj

            On May 31, 2010, at 12:24 PM, Tara Santmire wrote:

            > George - Thanks for taking the time to reply.
            >
            > I like the concept of taking the simplest path through the process first.
            > My guess is that the PO will want to do the most likely case first as that
            > has more business value. That could still be a valuable prioritization. At
            > each choice point say which is more likely and go down that path. Gets you
            > one way through the entire process.
            >
            > Tara E. Santmire, CSM, PMP
            > tara@...
            >
            > -----Original Message-----
            > From: scrumdevelopment@yahoogroups.com
            > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of George Dinwiddie
            > Sent: Monday, May 31, 2010 1:25 PM
            > To: scrumdevelopment@yahoogroups.com
            > Subject: Re: [scrumdevelopment] Prioritization of Stories in Business
            > Productivity Automation
            >
            > Tara,
            >
            > Tara Santmire wrote:
            > >
            > >
            > > I am the Scrum Master on a software development project building a web
            > > portal and automating a set of business processes. We are at the very
            > > beginning of the product/project and are building enough of the product
            > > backlog to have work for several sprints. The product owner has picked
            > > a particular business process to automate first (highest business
            > > value). We have identified some high level capabilities (home page,
            > > task lists, request lists, friendly nags, reporting, etc.) that cross
            > > business processes and steps within a process and have associated user
            > > stories which are identified as high priority. The rest of the user
            > > stories have to do with specific capabilities necessary for the various
            > > steps in the business process. The team has agreed that there are no
            > > big technical risks in any of these user stories. The product owner
            > > wants to prioritize these stories in the same order that they occur in
            > > the business process. I don't see any problems with this, but I have a
            > > nagging feeling that I am missing something. Does this seem like a
            > > reasonable way of prioritizing the stories? Does it have any potential
            > > drawbacks?
            >
            > That /seems/ like a reasonable order, but I suspect that the stories
            > you've identified may not really be the most functional stories. For
            > example, what sort of story is "home page?"
            >
            > I would suggest slicing things differently. Make the first slice the
            > /entire/ business process, for the simplest case you can imagine and
            > with little or no choices along the way. Make it work all the way
            > through, but only for that one narrow set of circumstances. Then start
            > to flesh it out for choosing other circumstances.
            >
            > I think you'll find this an easier route, and you'll generate a better
            > app, if you approach it this way. It's just a simple trick of the mind
            > to envision it this way rather than the steps of the business process.
            >
            > Please report back how things go for you.
            >
            > - George
            >
            > --
            > ----------------------------------------------------------
            > * George Dinwiddie * http://blog.gdinwiddie.com
            > Software Development http://www.idiacomputing.com
            > Consultant and Coach http://www.agilemaryland.org
            > ----------------------------------------------------------
            >
            > ------------------------------------
            >
            > To Post a message, send it to: scrumdevelopment@...
            > To Unsubscribe, send a blank message to:
            > scrumdevelopment-unsubscribe@...! Groups Links
            >
            >
          • Tara Santmire
            Michael - Thanks for taking the time to reply. Good advice - I suspect that this project will get a bit tricky as I expect the business process to change even
            Message 5 of 28 , May 31, 2010
            • 0 Attachment
              Michael - Thanks for taking the time to reply.

              Good advice - I suspect that this project will get a bit tricky as I expect
              the business process to change even before we develop the automation for a
              single path through the process. We are planning on two week sprints and I
              think that the product backlog grooming every two weeks will get
              interesting. The team I think will be ok with this. We had some changes in
              direction on our last project and they came through with really high morale
              and I think that was because there was little wasted effort involved. (I
              love Scrum and I am NOT doing waterfall again.) I am more worried about the
              PO, who may want to try to hold the business process in stone until we get
              enough done to deploy a meaningful release. I don't think that will work.
              Time will tell. I will post more as we move through our first sprints.

              Tara E. Santmire, CSM, PMP
              tara@...


              -----Original Message-----
              From: scrumdevelopment@yahoogroups.com
              [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Michael James
              Sent: Monday, May 31, 2010 3:46 PM
              To: scrumdevelopment@yahoogroups.com
              Subject: Re: [scrumdevelopment] Prioritization of Stories in Business
              Productivity Automation

              Adding to George's response, keep reminding both the Product Owner and
              development team that the Product Backlog is subject to constant revision
              and reprioritization. Chet Hendrickson wrote "We know less about the
              project today than at any time in the future." Even though those business
              processes appear to be locked down at the moment, it's likely that people
              will think of improvements, clarifications, fall behind schedule, etc. Some
              of your requirements can probably be split so that 80% of the value is
              derived from 20% of the effort of the original requirement. An attentive
              Product Owner is always looking for opportunities to slice and dice so high
              value work is done first.

              --mj

              On May 31, 2010, at 12:24 PM, Tara Santmire wrote:

              > George - Thanks for taking the time to reply.
              >
              > I like the concept of taking the simplest path through the process first.
              > My guess is that the PO will want to do the most likely case first as that
              > has more business value. That could still be a valuable prioritization. At
              > each choice point say which is more likely and go down that path. Gets you
              > one way through the entire process.
              >
              > Tara E. Santmire, CSM, PMP
              > tara@...
              >
              > -----Original Message-----
              > From: scrumdevelopment@yahoogroups.com
              > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of George Dinwiddie
              > Sent: Monday, May 31, 2010 1:25 PM
              > To: scrumdevelopment@yahoogroups.com
              > Subject: Re: [scrumdevelopment] Prioritization of Stories in Business
              > Productivity Automation
              >
              > Tara,
              >
              > Tara Santmire wrote:
              > >
              > >
              > > I am the Scrum Master on a software development project building a web
              > > portal and automating a set of business processes. We are at the very
              > > beginning of the product/project and are building enough of the product
              > > backlog to have work for several sprints. The product owner has picked
              > > a particular business process to automate first (highest business
              > > value). We have identified some high level capabilities (home page,
              > > task lists, request lists, friendly nags, reporting, etc.) that cross
              > > business processes and steps within a process and have associated user
              > > stories which are identified as high priority. The rest of the user
              > > stories have to do with specific capabilities necessary for the various
              > > steps in the business process. The team has agreed that there are no
              > > big technical risks in any of these user stories. The product owner
              > > wants to prioritize these stories in the same order that they occur in
              > > the business process. I don't see any problems with this, but I have a
              > > nagging feeling that I am missing something. Does this seem like a
              > > reasonable way of prioritizing the stories? Does it have any potential
              > > drawbacks?
              >
              > That /seems/ like a reasonable order, but I suspect that the stories
              > you've identified may not really be the most functional stories. For
              > example, what sort of story is "home page?"
              >
              > I would suggest slicing things differently. Make the first slice the
              > /entire/ business process, for the simplest case you can imagine and
              > with little or no choices along the way. Make it work all the way
              > through, but only for that one narrow set of circumstances. Then start
              > to flesh it out for choosing other circumstances.
              >
              > I think you'll find this an easier route, and you'll generate a better
              > app, if you approach it this way. It's just a simple trick of the mind
              > to envision it this way rather than the steps of the business process.
              >
              > Please report back how things go for you.
              >
              > - George
              >
              > --
              > ----------------------------------------------------------
              > * George Dinwiddie * http://blog.gdinwiddie.com
              > Software Development http://www.idiacomputing.com
              > Consultant and Coach http://www.agilemaryland.org
              > ----------------------------------------------------------
              >
              > ------------------------------------
              >
              > To Post a message, send it to: scrumdevelopment@...
              > To Unsubscribe, send a blank message to:
              > scrumdevelopment-unsubscribe@...! Groups Links
              >
              >



              ------------------------------------

              To Post a message, send it to: scrumdevelopment@...
              To Unsubscribe, send a blank message to:
              scrumdevelopment-unsubscribe@...! Groups Links
            • Ron Jeffries
              ... It seems unlikely to me that the business value of the stories is decreasing with ordinal position in the business process. It seems unlikely to me that
              Message 6 of 28 , May 31, 2010
              • 0 Attachment
                Hello, Tara. On Monday, May 31, 2010, at 8:23:52 AM, you wrote:

                > The product owner wants to prioritize these stories in the same
                > order that they occur in the business process. I don't see any problems
                > with this, but I have a nagging feeling that I am missing something. Does
                > this seem like a reasonable way of prioritizing the stories? Does it have
                > any potential drawbacks?

                It seems unlikely to me that the business value of the stories is
                decreasing with ordinal position in the business process. It seems
                unlikely to me that the risk of the stories decreases with ordinal
                position in the business process. It seems unlikely to me that the
                amount we need to learn decreases with ordinal position in the
                business process.

                Therefore it seems unlikely to me that priority is in same order as
                the position of the item in the business process.

                Ron Jeffries
                www.XProgramming.com
                www.xprogramming.com/blog
                You can observe a lot by watching. --Yogi Berra
              • Tara Santmire
                Ron - Thanks for taking the time to reply. On business value - I think that the PO is taking the point of view that she does not want to deploy until the
                Message 7 of 28 , May 31, 2010
                • 0 Attachment

                  Ron – Thanks for taking the time to reply.

                   

                  On business value – I think that the PO is taking the point of view that she does not want to deploy until the entire process is deployable and so there is no business value in partial process so just do it in order.  Do you have any suggestions about how I might disabuse her of that notion?  Or might she be correct?  Even if she is wrong, if she is so engrained in thinking this through in terms of the process, might there be value in proceeding in this order?

                   

                  On risk – the team has reviewed the process and the associated user stories and their estimation of technical risk is that they are all in the same bin.  The team feels that they have done something fairly similar, for the various pieces of the process.  I can try and go back and elicit more granularity. 

                   

                  On amount to learn – you may be right.  I don’t have good ideas about how to elicit more information about prioritization in terms of “amount we need to learn”.  Do you have suggestions?  Even if you are correct, if the PO and users are so engrained in thinking this through in terms of the process, might there be value in proceeding in this order as this is the only way they can think through all the ramifications of decisions?

                   

                   

                  Tara E. Santmire, CSM, PMP
                  tara@...

                   

                  From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
                  Sent: Monday, May 31, 2010 7:07 PM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                   

                   

                  Hello, Tara. On Monday, May 31, 2010, at 8:23:52 AM, you wrote:

                  > The product owner wants to prioritize these stories in the same
                  > order that they occur in the business process. I don't see any problems
                  > with this, but I have a nagging feeling that I am missing something. Does
                  > this seem like a reasonable way of prioritizing the stories? Does it have
                  > any potential drawbacks?

                  It seems unlikely to me that the business value of the stories is
                  decreasing with ordinal position in the business process. It seems
                  unlikely to me that the risk of the stories decreases with ordinal
                  position in the business process. It seems unlikely to me that the
                  amount we need to learn decreases with ordinal position in the
                  business process.

                  Therefore it seems unlikely to me that priority is in same order as
                  the position of the item in the business process.

                  Ron Jeffries
                  www.XProgramming.com
                  www.xprogramming.com/blog
                  You can observe a lot by watching. --Yogi Berra

                • Dan Rawsthorne
                  Great statement, mj, but I have one small nit... I think that an attentive TEAM is always looking... it is putting too much reliance on the PO the way it is
                  Message 8 of 28 , May 31, 2010
                  • 0 Attachment
                    Great statement, mj, but I have one small nit... I think that an
                    attentive TEAM is always looking... it is putting too much reliance on
                    the PO the way it is stated. BTW, I think that too many people think of
                    the PO as some sort of superhuman person, rather than as a role that can
                    share some of its responsibilities with the rest of the team - as part
                    of the self-organizing team.

                    Dan Rawsthorne, PhD, CST
                    Senior Trainer/Coach, CollabNet
                    drawsthorne@..., 425-269-8628



                    Michael James wrote:
                    > Adding to George's response, keep reminding both the Product Owner and development team that the Product Backlog is subject to constant revision and reprioritization. Chet Hendrickson wrote "We know less about the project today than at any time in the future." Even though those business processes appear to be locked down at the moment, it's likely that people will think of improvements, clarifications, fall behind schedule, etc. Some of your requirements can probably be split so that 80% of the value is derived from 20% of the effort of the original requirement. An attentive Product Owner is always looking for opportunities to slice and dice so high value work is done first.
                    >
                    > --mj
                    >
                    > On May 31, 2010, at 12:24 PM, Tara Santmire wrote:
                    >
                    >
                    >> George - Thanks for taking the time to reply.
                    >>
                    >> I like the concept of taking the simplest path through the process first.
                    >> My guess is that the PO will want to do the most likely case first as that
                    >> has more business value. That could still be a valuable prioritization. At
                    >> each choice point say which is more likely and go down that path. Gets you
                    >> one way through the entire process.
                    >>
                    >> Tara E. Santmire, CSM, PMP
                    >> tara@...
                    >>
                    >> -----Original Message-----
                    >> From: scrumdevelopment@yahoogroups.com
                    >> [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of George Dinwiddie
                    >> Sent: Monday, May 31, 2010 1:25 PM
                    >> To: scrumdevelopment@yahoogroups.com
                    >> Subject: Re: [scrumdevelopment] Prioritization of Stories in Business
                    >> Productivity Automation
                    >>
                    >> Tara,
                    >>
                    >> Tara Santmire wrote:
                    >>
                    >>> I am the Scrum Master on a software development project building a web
                    >>> portal and automating a set of business processes. We are at the very
                    >>> beginning of the product/project and are building enough of the product
                    >>> backlog to have work for several sprints. The product owner has picked
                    >>> a particular business process to automate first (highest business
                    >>> value). We have identified some high level capabilities (home page,
                    >>> task lists, request lists, friendly nags, reporting, etc.) that cross
                    >>> business processes and steps within a process and have associated user
                    >>> stories which are identified as high priority. The rest of the user
                    >>> stories have to do with specific capabilities necessary for the various
                    >>> steps in the business process. The team has agreed that there are no
                    >>> big technical risks in any of these user stories. The product owner
                    >>> wants to prioritize these stories in the same order that they occur in
                    >>> the business process. I don't see any problems with this, but I have a
                    >>> nagging feeling that I am missing something. Does this seem like a
                    >>> reasonable way of prioritizing the stories? Does it have any potential
                    >>> drawbacks?
                    >>>
                    >> That /seems/ like a reasonable order, but I suspect that the stories
                    >> you've identified may not really be the most functional stories. For
                    >> example, what sort of story is "home page?"
                    >>
                    >> I would suggest slicing things differently. Make the first slice the
                    >> /entire/ business process, for the simplest case you can imagine and
                    >> with little or no choices along the way. Make it work all the way
                    >> through, but only for that one narrow set of circumstances. Then start
                    >> to flesh it out for choosing other circumstances.
                    >>
                    >> I think you'll find this an easier route, and you'll generate a better
                    >> app, if you approach it this way. It's just a simple trick of the mind
                    >> to envision it this way rather than the steps of the business process.
                    >>
                    >> Please report back how things go for you.
                    >>
                    >> - George
                    >>
                    >> --
                    >> ----------------------------------------------------------
                    >> * George Dinwiddie * http://blog.gdinwiddie.com
                    >> Software Development http://www.idiacomputing.com
                    >> Consultant and Coach http://www.agilemaryland.org
                    >> ----------------------------------------------------------
                    >>
                    >> ------------------------------------
                    >>
                    >> To Post a message, send it to: scrumdevelopment@...
                    >> To Unsubscribe, send a blank message to:
                    >> scrumdevelopment-unsubscribe@...! Groups Links
                    >>
                    >>
                    >>
                    >
                    >
                    >
                    > ------------------------------------
                    >
                    > To Post a message, send it to: scrumdevelopment@...
                    > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                    >
                    >
                    >
                    >
                    >
                    >
                    >
                    > =======
                    > Email scanned by PC Tools - No viruses or spyware found.
                    > (Email Guard: 7.0.0.18, Virus/Spyware Database: 6.15110)
                    > http://www.pctools.com/
                    > =======
                    >
                    >
                  • Michael James
                    Point taken. Continuous backlog refinement is a whole team responsibility, with PO making final call on prioritization. --mj
                    Message 9 of 28 , May 31, 2010
                    • 0 Attachment
                      Point taken. Continuous backlog refinement is a whole team responsibility, with PO making final call on prioritization.

                      --mj


                      On May 31, 2010, at 8:12 PM, Dan Rawsthorne wrote:

                      > Great statement, mj, but I have one small nit... I think that an
                      > attentive TEAM is always looking... it is putting too much reliance on
                      > the PO the way it is stated. BTW, I think that too many people think of
                      > the PO as some sort of superhuman person, rather than as a role that can
                      > share some of its responsibilities with the rest of the team - as part
                      > of the self-organizing team.
                      >
                      > Dan Rawsthorne, PhD, CST
                      > Senior Trainer/Coach, CollabNet
                      > drawsthorne@..., 425-269-8628
                      >
                      >
                      >
                      > Michael James wrote:
                      >> Adding to George's response, keep reminding both the Product Owner and development team that the Product Backlog is subject to constant revision and reprioritization. Chet Hendrickson wrote "We know less about the project today than at any time in the future." Even though those business processes appear to be locked down at the moment, it's likely that people will think of improvements, clarifications, fall behind schedule, etc. Some of your requirements can probably be split so that 80% of the value is derived from 20% of the effort of the original requirement. An attentive Product Owner is always looking for opportunities to slice and dice so high value work is done first.
                      >>
                      >> --mj
                      >>
                      >> On May 31, 2010, at 12:24 PM, Tara Santmire wrote:
                      >>
                      >>
                      >>> George - Thanks for taking the time to reply.
                      >>>
                      >>> I like the concept of taking the simplest path through the process first.
                      >>> My guess is that the PO will want to do the most likely case first as that
                      >>> has more business value. That could still be a valuable prioritization. At
                      >>> each choice point say which is more likely and go down that path. Gets you
                      >>> one way through the entire process.
                      >>>
                      >>> Tara E. Santmire, CSM, PMP
                      >>> tara@...
                      >>>
                      >>> -----Original Message-----
                      >>> From: scrumdevelopment@yahoogroups.com
                      >>> [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of George Dinwiddie
                      >>> Sent: Monday, May 31, 2010 1:25 PM
                      >>> To: scrumdevelopment@yahoogroups.com
                      >>> Subject: Re: [scrumdevelopment] Prioritization of Stories in Business
                      >>> Productivity Automation
                      >>>
                      >>> Tara,
                      >>>
                      >>> Tara Santmire wrote:
                      >>>
                      >>>> I am the Scrum Master on a software development project building a web
                      >>>> portal and automating a set of business processes. We are at the very
                      >>>> beginning of the product/project and are building enough of the product
                      >>>> backlog to have work for several sprints. The product owner has picked
                      >>>> a particular business process to automate first (highest business
                      >>>> value). We have identified some high level capabilities (home page,
                      >>>> task lists, request lists, friendly nags, reporting, etc.) that cross
                      >>>> business processes and steps within a process and have associated user
                      >>>> stories which are identified as high priority. The rest of the user
                      >>>> stories have to do with specific capabilities necessary for the various
                      >>>> steps in the business process. The team has agreed that there are no
                      >>>> big technical risks in any of these user stories. The product owner
                      >>>> wants to prioritize these stories in the same order that they occur in
                      >>>> the business process. I don't see any problems with this, but I have a
                      >>>> nagging feeling that I am missing something. Does this seem like a
                      >>>> reasonable way of prioritizing the stories? Does it have any potential
                      >>>> drawbacks?
                      >>>>
                      >>> That /seems/ like a reasonable order, but I suspect that the stories
                      >>> you've identified may not really be the most functional stories. For
                      >>> example, what sort of story is "home page?"
                      >>>
                      >>> I would suggest slicing things differently. Make the first slice the
                      >>> /entire/ business process, for the simplest case you can imagine and
                      >>> with little or no choices along the way. Make it work all the way
                      >>> through, but only for that one narrow set of circumstances. Then start
                      >>> to flesh it out for choosing other circumstances.
                      >>>
                      >>> I think you'll find this an easier route, and you'll generate a better
                      >>> app, if you approach it this way. It's just a simple trick of the mind
                      >>> to envision it this way rather than the steps of the business process.
                      >>>
                      >>> Please report back how things go for you.
                      >>>
                      >>> - George
                      >>>
                      >>> --
                      >>> ----------------------------------------------------------
                      >>> * George Dinwiddie * http://blog.gdinwiddie.com
                      >>> Software Development http://www.idiacomputing.com
                      >>> Consultant and Coach http://www.agilemaryland.org
                      >>> ----------------------------------------------------------
                      >>>
                      >>> ------------------------------------
                      >>>
                      >>> To Post a message, send it to: scrumdevelopment@...
                      >>> To Unsubscribe, send a blank message to:
                      >>> scrumdevelopment-unsubscribe@...! Groups Links
                      >>>
                      >>>
                      >>>
                      >>
                      >>
                      >>
                      >> ------------------------------------
                      >>
                      >> To Post a message, send it to: scrumdevelopment@...
                      >> To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                      >>
                      >>
                      >>
                      >>
                      >>
                      >>
                      >>
                      >> =======
                      >> Email scanned by PC Tools - No viruses or spyware found.
                      >> (Email Guard: 7.0.0.18, Virus/Spyware Database: 6.15110)
                      >> http://www.pctools.com/
                      >> =======
                      >>
                      >>
                      >
                      >
                      > ------------------------------------
                      >
                      > To Post a message, send it to: scrumdevelopment@...
                      > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                      >
                      >
                      >
                    • Peter Stevens (calendar)
                      Hi Tara, You have identified one way to think about the business process: Considering it as a sequence of steps to be executed one after the other. Is that the
                      Message 10 of 28 , May 31, 2010
                      • 0 Attachment
                        Hi Tara,

                        You have identified one way to think about the business process: Considering it as a sequence of steps to be executed one after the other. Is that the only way to think about it? Is it the best way?

                        I once worked for a company which had a several processes to automate. The first such project I worked on, the program was conceived to implement its process step by step. This seemed logical at the time, but it made the software extremely difficult to test or change, and equally inflexible for the user.

                        Later, I worked with two domain experts on the visioning of a similar project. We found that if we took an objected-oriented approach, the process became much simpler: The user would create a dossier, the former steps in the process became operations on the dossier, and a new 'make it so' operation (order) would complete the process. Once a dossier was created, it could be completed. The steps in the middle became optional (even though they remained important enough that most users in most cases would apply them). This made it possible for the P-O to prioritize the value of the operations, but also to add or remove alternatives in repesonse to changing priorities, time pressures, user/customer demands etc.

                        For example: Most airline ticketing processes are sequential: 1) enter travel dates, number of passengers and departure and destination point 2) find flights 3) select flights 4) decide to order, 6) identify passengers 7) pay. What happens if your mother in law decides to join you on the trip? You have to start over. Why not just add her to the dossier? Why do you have to reenter the passenger data every time you want to consider a new alternative?

                        If you were going to apply the dossier approach to airline ticketing, how would you do it? Which functions would you implement first? Maybe create dossier, pay for flight. Once these are implemented, you can potentially generate revenue. Next might be select alternative flights by price or by schedule, add spouse and kids. Now the customers can easily book the flight they want and bring the whole family. Probably adding your mother-in-law after the rest of the family has already booked a ticket won't be top on your priority list, but you may decide it's important later (especially if she offers to babysit ;-) ). Of course, this function will be competing with 'book rental car' and hotel booking functions which might have more value...

                        If you were going to apply this approach to your application, how would you do it? What advantages and disadvantages would you have? Why are the advantages more important (or why aren't they)?

                        Cheers,

                        Peter

                        On 01.06.10 02:07, Tara Santmire wrote:  

                        Ron – Thanks for taking the time to reply.

                         

                        On business value – I think that the PO is taking the point of view that she does not want to deploy until the entire process is deployable and so there is no business value in partial process so just do it in order.  Do you have any suggestions about how I might disabuse her of that notion?  Or might she be correct?  Even if she is wrong, if she is so engrained in thinking this through in terms of the process, might there be value in proceeding in this order?

                         

                        On risk – the team has reviewed the process and the associated user stories and their estimation of technical risk is that they are all in the same bin.  The team feels that they have done something fairly similar, for the various pieces of the process.  I can try and go back and elicit more granularity. 

                         

                        On amount to learn – you may be right.  I don’t have good ideas about how to elicit more information about prioritization in terms of “amount we need to learn”.  Do you have suggestions?  Even if you are correct, if the PO and users are so engrained in thinking this through in terms of the process, might there be value in proceeding in this order as this is the only way they can think through all the ramifications of decisions?

                         

                         

                        Tara E. Santmire, CSM, PMP
                        tara@maresreach. net

                         

                        From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of Ron Jeffries
                        Sent: Monday, May 31, 2010 7:07 PM
                        To: scrumdevelopment@ yahoogroups. com
                        Subject: Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                         

                         

                        Hello, Tara. On Monday, May 31, 2010, at 8:23:52 AM, you wrote:

                        > The product owner wants to prioritize these stories in the same
                        > order that they occur in the business process. I don't see any problems
                        > with this, but I have a nagging feeling that I am missing something. Does
                        > this seem like a reasonable way of prioritizing the stories? Does it have
                        > any potential drawbacks?

                        It seems unlikely to me that the business value of the stories is
                        decreasing with ordinal position in the business process. It seems
                        unlikely to me that the risk of the stories decreases with ordinal
                        position in the business process. It seems unlikely to me that the
                        amount we need to learn decreases with ordinal position in the
                        business process.

                        Therefore it seems unlikely to me that priority is in same order as
                        the position of the item in the business process.

                        Ron Jeffries
                        www.XProgramming. com
                        www.xprogramming. com/blog
                        You can observe a lot by watching. --Yogi Berra



                        -- 
                        Peter Stevens, CSM, CSPO, CSP
                        www.scrum-breakfast.com
                        tel: +41 44 586 6450 
                        
                      • Roy Morien
                        I would like to make a quick comment on the matter of deploying. There is a significant risk in waiting to deploy until the whole product is finished. A big
                        Message 11 of 28 , May 31, 2010
                        • 0 Attachment
                          I would like to make a quick comment on the matter of deploying.
                           
                          There is a significant risk in waiting to deploy until the whole product is finished. A 'big bang' deployment can come unstuck very easily, as we have seen many times. It is an all or nothing scenario, with the potential to be very disruptive.
                           
                          I do not see deployment of part of the system as necessarilly deploying into a production mode. There is a lot of value in deploying parts of the system as they are developed, assuming, of course, that the parts being deployed are a reasonably complete and exercisable sub-set. But even a single report can be usefully deployed.
                           
                          Doing it this way gives the users an opportunity to train on the software, to exercise the software, potentially finding bugs that always seem to occur when a user uses the software in a particular way, unforeseen previously. It also gives the opportunity for feedback about changes, and new requirements that using the software elicits.
                           
                          So there is a little-by-little flow of training, feedback, familiarisation etc. that is extremely valuable.
                           
                          Also, the mere fact that users see progress, manifested by usable parts being given to them regularly and frequently, keeps the project visible, giving users more confidence (and the developers) that things are on-track. The old feeling of 'we'll never see anything from this long, drawn-out process, that is invisible to us anyway' is overcome.
                           
                          Regards,
                          Roy Morien
                           

                          To: scrumdevelopment@yahoogroups.com
                          From: tara@...
                          Date: Mon, 31 May 2010 20:07:41 -0400
                          Subject: RE: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                           

                          Ron – Thanks for taking the time to reply.

                           

                          On business value – I think that the PO is taking the point of view that she does not want to deploy until the entire process is deployable and so there is no business value in partial process so just do it in order.  Do you have any suggestions about how I might disabuse her of that notion?  Or might she be correct?  Even if she is wrong, if she is so engrained in thinking this through in terms of the process, might there be value in proceeding in this order?

                           

                          On risk – the team has reviewed the process and the associated user stories and their estimation of technical risk is that they are all in the same bin.  The team feels that they have done something fairly similar, for the various pieces of the process.  I can try and go back and elicit more granularity. 

                           

                          On amount to learn – you may be right.  I don’t have good ideas about how to elicit more information about prioritization in terms of “amount we need to learn”.  Do you have suggestions?  Even if you are correct, if the PO and users are so engrained in thinking this through in terms of the process, might there be value in proceeding in this order as this is the only way they can think through all the ramifications of decisions?

                           

                           

                          Tara E. Santmire, CSM, PMP
                          tara@maresreach. net

                           

                          From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of Ron Jeffries
                          Sent: Monday, May 31, 2010 7:07 PM
                          To: scrumdevelopment@ yahoogroups. com
                          Subject: Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                           

                           

                          Hello, Tara. On Monday, May 31, 2010, at 8:23:52 AM, you wrote:

                          > The product owner wants to prioritize these stories in the same
                          > order that they occur in the business process. I don't see any problems
                          > with this, but I have a nagging feeling that I am missing something. Does
                          > this seem like a reasonable way of prioritizing the stories? Does it have
                          > any potential drawbacks?

                          It seems unlikely to me that the business value of the stories is
                          decreasing with ordinal position in the business process. It seems
                          unlikely to me that the risk of the stories decreases with ordinal
                          position in the business process. It seems unlikely to me that the
                          amount we need to learn decreases with ordinal position in the
                          business process.

                          Therefore it seems unlikely to me that priority is in same order as
                          the position of the item in the business process.

                          Ron Jeffries
                          www.XProgramming. com
                          www.xprogramming. com/blog
                          You can observe a lot by watching. --Yogi Berra




                          Meet local singles online. Browse profiles for FREE!
                        • Roy Morien
                          Prioritising the Product Backlog to reflect the sequence of activities in the business process seems logical, on the face of it ... but ... Are business
                          Message 12 of 28 , May 31, 2010
                          • 0 Attachment
                            Prioritising the Product Backlog to reflect the sequence of activities in the business process seems logical, on the face of it ... but ...
                             
                            Are business processes always 'sequential', such that one sub-process is always used before another specific one, and after another specific one? I would suggest not. Are they 'sequential' in that many users can be using each or any 'sub-process' dependant on what any other user is doing at that time? Again, I would suggest not. There is always some degree of randomness about who is doing what while someone else is doing th same, or something else. There is no 'sequence' obvious in this.
                             
                            The purpose of prioritising the Product Backlog is to ensure that high-value processes are delivered first, so that all that remains to be done at ay one time is of lower, or low value.
                             
                            Having said that, if tracing a path through the usual way of doing things provides a good framework for deciding on business value, then why not do it that way. But always keeping in mind that just because someone wants a report after they have done something else does not raise that report to a high level of priority, necessarilly.
                             
                            Regards,
                            Roy Morien
                             

                            To: scrumdevelopment@yahoogroups.com
                            From: peterstev@...
                            Date: Tue, 1 Jun 2010 05:48:39 +0200
                            Subject: Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                             
                            Hi Tara,

                            You have identified one way to think about the business process: Considering it as a sequence of steps to be executed one after the other. Is that the only way to think about it? Is it the best way?

                            I once worked for a company which had a several processes to automate. The first such project I worked on, the program was conceived to implement its process step by step. This seemed logical at the time, but it made the software extremely difficult to test or change, and equally inflexible for the user.

                            Later, I worked with two domain experts on the visioning of a similar project. We found that if we took an objected-oriented approach, the process became much simpler: The user would create a dossier, the former steps in the process became operations on the dossier, and a new 'make it so' operation (order) would complete the process. Once a dossier was created, it could be completed. The steps in the middle became optional (even though they remained important enough that most users in most cases would apply them). This made it possible for the P-O to prioritize the value of the operations, but also to add or remove alternatives in repesonse to changing priorities, time pressures, user/customer demands etc.

                            For example: Most airline ticketing processes are sequential: 1) enter travel dates, number of passengers and departure and destination point 2) find flights 3) select flights 4) decide to order, 6) identify passengers 7) pay. What happens if your mother in law decides to join you on the trip? You have to start over. Why not just add her to the dossier? Why do you have to reenter the passenger data every time you want to consider a new alternative?

                            If you were going to apply the dossier approach to airline ticketing, how would you do it? Which functions would you implement first? Maybe create dossier, pay for flight. Once these are implemented, you can potentially generate revenue. Next might be select alternative flights by price or by schedule, add spouse and kids. Now the customers can easily book the flight they want and bring the whole family. Probably adding your mother-in-law after the rest of the family has already booked a ticket won't be top on your priority list, but you may decide it's important later (especially if she offers to babysit ;-) ). Of course, this function will be competing with 'book rental car' and hotel booking functions which might have more value...

                            If you were going to apply this approach to your application, how would you do it? What advantages and disadvantages would you have? Why are the advantages more important (or why aren't they)?

                            Cheers,

                            Peter

                            On 01.06.10 02:07, Tara Santmire wrote:
                             


                            Ron – Thanks for taking the time to reply.

                             

                            On business value – I think that the PO is taking the point of view that she does not want to deploy until the entire process is deployable and so there is no business value in partial process so just do it in order.  Do you have any suggestions about how I might disabuse her of that notion?  Or might she be correct?  Even if she is wrong, if she is so engrained in thinking this through in terms of the process, might there be value in proceeding in this order?

                             

                            On risk – the team has reviewed the process and the associated user stories and their estimation of technical risk is that they are all in the same bin.  The team feels that they have done something fairly similar, for the various pieces of the process.  I can try and go back and elicit more granularity. 

                             

                            On amount to learn – you may be right.  I don’t have good ideas about how to elicit more information about prioritization in terms of “amount we need to learn”.  Do you have suggestions?  Even if you are correct, if the PO and users are so engrained in thinking this through in terms of the process, might there be value in proceeding in this order as this is the only way they can think through all the ramifications of decisions?

                             

                             

                            Tara E. Santmire, CSM, PMP
                            tara@maresreach. net

                             

                            From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of Ron Jeffries
                            Sent: Monday, May 31, 2010 7:07 PM
                            To: scrumdevelopment@ yahoogroups. com
                            Subject: Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                             

                             

                            Hello, Tara. On Monday, May 31, 2010, at 8:23:52 AM, you wrote:

                            > The product owner wants to prioritize these stories in the same
                            > order that they occur in the business process. I don't see any problems
                            > with this, but I have a nagging feeling that I am missing something. Does
                            > this seem like a reasonable way of prioritizing the stories? Does it have
                            > any potential drawbacks?

                            It seems unlikely to me that the business value of the stories is
                            decreasing with ordinal position in the business process. It seems
                            unlikely to me that the risk of the stories decreases with ordinal
                            position in the business process. It seems unlikely to me that the
                            amount we need to learn decreases with ordinal position in the
                            business process.

                            Therefore it seems unlikely to me that priority is in same order as
                            the position of the item in the business process.

                            Ron Jeffries
                            www.XProgramming. com
                            www.xprogramming. com/blog
                            You can observe a lot by watching. --Yogi Berra



                            -- 
                            Peter Stevens, CSM, CSPO, CSP
                            www.scrum-breakfast .com
                            tel: +41 44 586 6450 
                            



                            Find it on Domain.com.au Need a new place to live?
                          • Dan Rawsthorne
                            Perfect. Dan Rawsthorne, PhD, CST Senior Trainer/Coach, CollabNet drawsthorne@collab.net, 425-269-8628
                            Message 13 of 28 , Jun 1, 2010
                            • 0 Attachment
                              Perfect.

                              Dan Rawsthorne, PhD, CST
                              Senior Trainer/Coach, CollabNet
                              drawsthorne@..., 425-269-8628



                              Michael James wrote:
                              >
                              > Point taken. Continuous backlog refinement is a whole team
                              > responsibility, with PO making final call on prioritization.
                              >
                              > --mj
                              >
                              > On May 31, 2010, at 8:12 PM, Dan Rawsthorne wrote:
                              >
                              > > Great statement, mj, but I have one small nit... I think that an
                              > > attentive TEAM is always looking... it is putting too much reliance on
                              > > the PO the way it is stated. BTW, I think that too many people think of
                              > > the PO as some sort of superhuman person, rather than as a role that
                              > can
                              > > share some of its responsibilities with the rest of the team - as part
                              > > of the self-organizing team.
                              > >
                              > > Dan Rawsthorne, PhD, CST
                              > > Senior Trainer/Coach, CollabNet
                              > > drawsthorne@... <mailto:drawsthorne%40collab.net>, 425-269-8628
                              > >
                              > >
                              > >
                              > > Michael James wrote:
                              > >> Adding to George's response, keep reminding both the Product Owner
                              > and development team that the Product Backlog is subject to constant
                              > revision and reprioritization. Chet Hendrickson wrote "We know less
                              > about the project today than at any time in the future." Even though
                              > those business processes appear to be locked down at the moment, it's
                              > likely that people will think of improvements, clarifications, fall
                              > behind schedule, etc. Some of your requirements can probably be split
                              > so that 80% of the value is derived from 20% of the effort of the
                              > original requirement. An attentive Product Owner is always looking for
                              > opportunities to slice and dice so high value work is done first.
                              > >>
                              > >> --mj
                              > >>
                              > >> On May 31, 2010, at 12:24 PM, Tara Santmire wrote:
                              > >>
                              > >>
                              > >>> George - Thanks for taking the time to reply.
                              > >>>
                              > >>> I like the concept of taking the simplest path through the process
                              > first.
                              > >>> My guess is that the PO will want to do the most likely case first
                              > as that
                              > >>> has more business value. That could still be a valuable
                              > prioritization. At
                              > >>> each choice point say which is more likely and go down that path.
                              > Gets you
                              > >>> one way through the entire process.
                              > >>>
                              > >>> Tara E. Santmire, CSM, PMP
                              > >>> tara@... <mailto:tara%40maresreach.net>
                              > >>>
                              > >>> -----Original Message-----
                              > >>> From: scrumdevelopment@yahoogroups.com
                              > <mailto:scrumdevelopment%40yahoogroups.com>
                              > >>> [mailto:scrumdevelopment@yahoogroups.com
                              > <mailto:scrumdevelopment%40yahoogroups.com>] On Behalf Of George Dinwiddie
                              > >>> Sent: Monday, May 31, 2010 1:25 PM
                              > >>> To: scrumdevelopment@yahoogroups.com
                              > <mailto:scrumdevelopment%40yahoogroups.com>
                              > >>> Subject: Re: [scrumdevelopment] Prioritization of Stories in Business
                              > >>> Productivity Automation
                              > >>>
                              > >>> Tara,
                              > >>>
                              > >>> Tara Santmire wrote:
                              > >>>
                              > >>>> I am the Scrum Master on a software development project building
                              > a web
                              > >>>> portal and automating a set of business processes. We are at the
                              > very
                              > >>>> beginning of the product/project and are building enough of the
                              > product
                              > >>>> backlog to have work for several sprints. The product owner has
                              > picked
                              > >>>> a particular business process to automate first (highest business
                              > >>>> value). We have identified some high level capabilities (home page,
                              > >>>> task lists, request lists, friendly nags, reporting, etc.) that
                              > cross
                              > >>>> business processes and steps within a process and have associated
                              > user
                              > >>>> stories which are identified as high priority. The rest of the user
                              > >>>> stories have to do with specific capabilities necessary for the
                              > various
                              > >>>> steps in the business process. The team has agreed that there are no
                              > >>>> big technical risks in any of these user stories. The product owner
                              > >>>> wants to prioritize these stories in the same order that they
                              > occur in
                              > >>>> the business process. I don't see any problems with this, but I
                              > have a
                              > >>>> nagging feeling that I am missing something. Does this seem like a
                              > >>>> reasonable way of prioritizing the stories? Does it have any
                              > potential
                              > >>>> drawbacks?
                              > >>>>
                              > >>> That /seems/ like a reasonable order, but I suspect that the stories
                              > >>> you've identified may not really be the most functional stories. For
                              > >>> example, what sort of story is "home page?"
                              > >>>
                              > >>> I would suggest slicing things differently. Make the first slice the
                              > >>> /entire/ business process, for the simplest case you can imagine and
                              > >>> with little or no choices along the way. Make it work all the way
                              > >>> through, but only for that one narrow set of circumstances. Then
                              > start
                              > >>> to flesh it out for choosing other circumstances.
                              > >>>
                              > >>> I think you'll find this an easier route, and you'll generate a
                              > better
                              > >>> app, if you approach it this way. It's just a simple trick of the
                              > mind
                              > >>> to envision it this way rather than the steps of the business process.
                              > >>>
                              > >>> Please report back how things go for you.
                              > >>>
                              > >>> - George
                              > >>>
                              > >>> --
                              > >>> ----------------------------------------------------------
                              > >>> * George Dinwiddie * http://blog.gdinwiddie.com
                              > >>> Software Development http://www.idiacomputing.com
                              > >>> Consultant and Coach http://www.agilemaryland.org
                              > >>> ----------------------------------------------------------
                              > >>>
                              > >>> ------------------------------------
                              > >>>
                              > >>> To Post a message, send it to: scrumdevelopment@...
                              > <mailto:scrumdevelopment%40eGroups.com>
                              > >>> To Unsubscribe, send a blank message to:
                              > >>> scrumdevelopment-unsubscribe@...
                              > <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
                              > >>>
                              > >>>
                              > >>>
                              > >>
                              > >>
                              > >>
                              > >> ------------------------------------
                              > >>
                              > >> To Post a message, send it to: scrumdevelopment@...
                              > <mailto:scrumdevelopment%40eGroups.com>
                              > >> To Unsubscribe, send a blank message to:
                              > scrumdevelopment-unsubscribe@...
                              > <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
                              > >>
                              > >>
                              > >>
                              > >>
                              > >>
                              > >>
                              > >>
                              > >> =======
                              > >> Email scanned by PC Tools - No viruses or spyware found.
                              > >> (Email Guard: 7.0.0.18, Virus/Spyware Database: 6.15110)
                              > >> http://www.pctools.com/
                              > >> =======
                              > >>
                              > >>
                              > >
                              > >
                              > > ------------------------------------
                              > >
                              > > To Post a message, send it to: scrumdevelopment@...
                              > <mailto:scrumdevelopment%40eGroups.com>
                              > > To Unsubscribe, send a blank message to:
                              > scrumdevelopment-unsubscribe@...
                              > <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
                              > >
                              > >
                              > >
                              >
                              >
                              >
                              >
                              >
                              >
                              >
                              > =======
                              > Email scanned by PC Tools - No viruses or spyware found.
                              > (Email Guard: 7.0.0.18, Virus/Spyware Database: 6.15120)
                              > http://www.pctools.com
                              > <http://www.pctools.com/?cclick=EmailFooterClean_51>
                              > =======
                            • Dan Rawsthorne
                              Interesting, Roy. Are you suggesting that the value described in paragraph 3 is the same as business value described in paragraph 4? If so, I disagree. I
                              Message 14 of 28 , Jun 1, 2010
                              • 0 Attachment
                                Interesting, Roy. Are you suggesting that the "value" described in
                                paragraph 3 is the same as "business value" described in paragraph 4? If
                                so, I disagree. I think the first is value to the Project, while the
                                second is value to the Client...

                                I like the following thought experiments.
                                1. Do we really want our team working on the highest-value business
                                processes when they are brand new, and don't have their sh*t together?
                                2. How do technical dependencies play in this?
                                3. How do personnel dependencies play in this?

                                Just sayin' Dan ;-)

                                Dan Rawsthorne, PhD, CST
                                Senior Trainer/Coach, CollabNet
                                drawsthorne@..., 425-269-8628



                                Roy Morien wrote:
                                >
                                >
                                > Prioritising the Product Backlog to reflect the sequence of activities
                                > in the business process seems logical, on the face of it ... but ...
                                >
                                > Are business processes always 'sequential', such that one sub-process
                                > is always used before another specific one, and after another specific
                                > one? I would suggest not. Are they 'sequential' in that many users can
                                > be using each or any 'sub-process' dependant on what any other user is
                                > doing at that time? Again, I would suggest not. There is always some
                                > degree of randomness about who is doing what while someone else is
                                > doing th same, or something else. There is no 'sequence' obvious in this.
                                >
                                > The purpose of prioritising the Product Backlog is to ensure that
                                > high-value processes are delivered first, so that all that remains to
                                > be done at ay one time is of lower, or low value.
                                >
                                > Having said that, if tracing a path through the usual way of doing
                                > things provides a good framework for deciding on business value, then
                                > why not do it that way. But always keeping in mind that just because
                                > someone wants a report after they have done something else does not
                                > raise that report to a high level of priority, necessarilly.
                                >
                                > Regards,
                                > Roy Morien
                                >
                                >
                                > ------------------------------------------------------------------------
                                > To: scrumdevelopment@yahoogroups.com
                                > From: peterstev@...
                                > Date: Tue, 1 Jun 2010 05:48:39 +0200
                                > Subject: Re: [scrumdevelopment] Prioritization of Stories in Business
                                > Productivity Automation
                                >
                                >
                                > Hi Tara,
                                >
                                > You have identified one way to think about the business process:
                                > Considering it as a sequence of steps to be executed one after the
                                > other. Is that the only way to think about it? Is it the best way?
                                >
                                > I once worked for a company which had a several processes to automate.
                                > The first such project I worked on, the program was conceived to
                                > implement its process step by step. This seemed logical at the time,
                                > but it made the software extremely difficult to test or change, and
                                > equally inflexible for the user.
                                >
                                > Later, I worked with two domain experts on the visioning of a similar
                                > project. We found that if we took an objected-oriented approach, the
                                > process became much simpler: The user would create a dossier, the
                                > former steps in the process became operations on the dossier, and a
                                > new 'make it so' operation (order) would complete the process. Once a
                                > dossier was created, it could be completed. The steps in the middle
                                > became optional (even though they remained important enough that most
                                > users in most cases would apply them). This made it possible for the
                                > P-O to prioritize the value of the operations, but also to add or
                                > remove alternatives in repesonse to changing priorities, time
                                > pressures, user/customer demands etc.
                                >
                                > For example: Most airline ticketing processes are sequential: 1) enter
                                > travel dates, number of passengers and departure and destination point
                                > 2) find flights 3) select flights 4) decide to order, 6) identify
                                > passengers 7) pay. What happens if your mother in law decides to join
                                > you on the trip? You have to start over.. Why not just add her to the
                                > dossier? Why do you have to reenter the passenger data every time you
                                > want to consider a new alternative?
                                >
                                > If you were going to apply the dossier approach to airline ticketing,
                                > how would you do it? Which functions would you implement first? Maybe
                                > create dossier, pay for flight. Once these are implemented, you can
                                > potentially generate revenue. Next might be select alternative flights
                                > by price or by schedule, add spouse and kids. Now the customers can
                                > easily book the flight they want and bring the whole family. Probably
                                > adding your mother-in-law after the rest of the family has already
                                > booked a ticket won't be top on your priority list, but you may decide
                                > it's important later (especially if she offers to babysit ;-) ). Of
                                > course, this function will be competing with 'book rental car' and
                                > hotel booking functions which might have more value...
                                >
                                > If you were going to apply this approach to your application, how
                                > would you do it? What advantages and disadvantages would you have? Why
                                > are the advantages more important (or why aren't they)?
                                >
                                > Cheers,
                                >
                                > Peter
                                >
                                > On 01.06.10 02:07, Tara Santmire wrote:
                                >
                                >
                                >
                                >
                                > Ron – Thanks for taking the time to reply.
                                >
                                >
                                >
                                > On business value – I think that the PO is taking the point of
                                > view that she does not want to deploy until the entire process is
                                > deployable and so there is no business value in partial process so
                                > just do it in order. Do you have any suggestions about how I
                                > might disabuse her of that notion? Or might she be correct? Even
                                > if she is wrong, if she is so engrained in thinking this through
                                > in terms of the process, might there be value in proceeding in
                                > this order?
                                >
                                >
                                >
                                > On risk – the team has reviewed the process and the associated
                                > user stories and their estimation of technical risk is that they
                                > are all in the same bin. The team feels that they have done
                                > something fairly similar, for the various pieces of the process.
                                > I can try and go back and elicit more granularity.
                                >
                                >
                                >
                                > On amount to learn – you may be right. I don’t have good ideas
                                > about how to elicit more information about prioritization in terms
                                > of “amount we need to learn”. Do you have suggestions? Even if
                                > you are correct, if the PO and users are so engrained in thinking
                                > this through in terms of the process, might there be value in
                                > proceeding in this order as this is the only way they can think
                                > through all the ramifications of decisions?
                                >
                                >
                                >
                                >
                                >
                                > Tara E. Santmire, CSM, PMP
                                > tara@...
                                >
                                >
                                >
                                > *From:* scrumdevelopment@yahoogroups.com
                                > [mailto:scrumdevelopment@yahoogroups.com] *On Behalf Of *Ron Jeffries
                                > *Sent:* Monday, May 31, 2010 7:07 PM
                                > *To:* scrumdevelopment@yahoogroups.com
                                > *Subject:* Re: [scrumdevelopment] Prioritization of Stories in
                                > Business Productivity Automation
                                >
                                >
                                >
                                >
                                >
                                > Hello, Tara. On Monday, May 31, 2010, at 8:23:52 AM, you wrote:
                                >
                                > > The product owner wants to prioritize these stories in the same
                                > > order that they occur in the business process. I don't see any
                                > problems
                                > > with this, but I have a nagging feeling that I am missing
                                > something. Does
                                > > this seem like a reasonable way of prioritizing the stories?
                                > Does it have
                                > > any potential drawbacks?
                                >
                                > It seems unlikely to me that the business value of the stories is
                                > decreasing with ordinal position in the business process. It seems
                                > unlikely to me that the risk of the stories decreases with ordinal
                                > position in the business process. It seems unlikely to me that the
                                > amount we need to learn decreases with ordinal position in the
                                > business process.
                                >
                                > Therefore it seems unlikely to me that priority is in same order as
                                > the position of the item in the business process.
                                >
                                > Ron Jeffries
                                > www.XProgramming <http://www.xprogramming/>.com
                                > www.xprogramming <http://www.xprogramming/>.com/blog
                                > You can observe a lot by watching. --Yogi Berra
                                >
                                >
                                >
                                > --
                                > Peter Stevens, CSM, CSPO, CSP
                                > www.scrum-breakfast.com <http://www.scrum-breakfast..com/>
                                > tel: +41 44 586 6450
                                >
                                >
                                >
                                > ------------------------------------------------------------------------
                                > Find it on Domain.com.au Need a new place to live?
                                > <http://clk.atdmt.com/NMN/go/157631292/direct/01/>
                                >
                                >
                                >
                                >
                                >
                                >
                                > =======
                                > Email scanned by PC Tools - No viruses or spyware found.
                                > (Email Guard: 7.0.0.18, Virus/Spyware Database: 6.15120)
                                > http://www.pctools.com
                                > <http://www.pctools.com/?cclick=EmailFooterClean_51>
                                > =======
                              • Tara Santmire
                                Peter - Thanks for taking the time to reply. The dossier approach is interesting and I will discuss with the team. I wonder though how much it saves you
                                Message 15 of 28 , Jun 1, 2010
                                • 0 Attachment

                                  Peter  - Thanks for taking the time to reply.  The dossier approach is interesting and I will discuss with the team.  I wonder though how much it saves you given the object oriented nature of programming with today’s workflow engines. 

                                   

                                  Tara E. Santmire, CSM, PMP
                                  tara@...

                                   

                                  From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Peter Stevens (calendar)
                                  Sent: Monday, May 31, 2010 11:49 PM
                                  To: scrumdevelopment@yahoogroups.com
                                  Subject: Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                   

                                   

                                  Hi Tara,

                                  You have identified one way to think about the business process: Considering it as a sequence of steps to be executed one after the other. Is that the only way to think about it? Is it the best way?

                                  I once worked for a company which had a several processes to automate. The first such project I worked on, the program was conceived to implement its process step by step. This seemed logical at the time, but it made the software extremely difficult to test or change, and equally inflexible for the user.

                                  Later, I worked with two domain experts on the visioning of a similar project. We found that if we took an objected-oriented approach, the process became much simpler: The user would create a dossier, the former steps in the process became operations on the dossier, and a new 'make it so' operation (order) would complete the process. Once a dossier was created, it could be completed. The steps in the middle became optional (even though they remained important enough that most users in most cases would apply them). This made it possible for the P-O to prioritize the value of the operations, but also to add or remove alternatives in repesonse to changing priorities, time pressures, user/customer demands etc.

                                  For example: Most airline ticketing processes are sequential: 1) enter travel dates, number of passengers and departure and destination point 2) find flights 3) select flights 4) decide to order, 6) identify passengers 7) pay. What happens if your mother in law decides to join you on the trip? You have to start over. Why not just add her to the dossier? Why do you have to reenter the passenger data every time you want to consider a new alternative?

                                  If you were going to apply the dossier approach to airline ticketing, how would you do it? Which functions would you implement first? Maybe create dossier, pay for flight. Once these are implemented, you can potentially generate revenue. Next might be select alternative flights by price or by schedule, add spouse and kids. Now the customers can easily book the flight they want and bring the whole family. Probably adding your mother-in-law after the rest of the family has already booked a ticket won't be top on your priority list, but you may decide it's important later (especially if she offers to babysit ;-) ). Of course, this function will be competing with 'book rental car' and hotel booking functions which might have more value...

                                  If you were going to apply this approach to your application, how would you do it? What advantages and disadvantages would you have? Why are the advantages more important (or why aren't they)?

                                  Cheers,

                                  Peter

                                  On 01.06.10 02:07, Tara Santmire wrote:

                                   

                                  Ron – Thanks for taking the time to reply.

                                   

                                  On business value – I think that the PO is taking the point of view that she does not want to deploy until the entire process is deployable and so there is no business value in partial process so just do it in order.  Do you have any suggestions about how I might disabuse her of that notion?  Or might she be correct?  Even if she is wrong, if she is so engrained in thinking this through in terms of the process, might there be value in proceeding in this order?

                                   

                                  On risk – the team has reviewed the process and the associated user stories and their estimation of technical risk is that they are all in the same bin.  The team feels that they have done something fairly similar, for the various pieces of the process.  I can try and go back and elicit more granularity. 

                                   

                                  On amount to learn – you may be right.  I don’t have good ideas about how to elicit more information about prioritization in terms of “amount we need to learn”.  Do you have suggestions?  Even if you are correct, if the PO and users are so engrained in thinking this through in terms of the process, might there be value in proceeding in this order as this is the only way they can think through all the ramifications of decisions?

                                   

                                   

                                  Tara E. Santmire, CSM, PMP
                                  tara@...

                                   

                                  From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
                                  Sent: Monday, May 31, 2010 7:07 PM
                                  To: scrumdevelopment@yahoogroups.com
                                  Subject: Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                   

                                   

                                  Hello, Tara. On Monday, May 31, 2010, at 8:23:52 AM, you wrote:

                                  > The product owner wants to prioritize these stories in the same
                                  > order that they occur in the business process. I don't see any problems
                                  > with this, but I have a nagging feeling that I am missing something. Does
                                  > this seem like a reasonable way of prioritizing the stories? Does it have
                                  > any potential drawbacks?

                                  It seems unlikely to me that the business value of the stories is
                                  decreasing with ordinal position in the business process. It seems
                                  unlikely to me that the risk of the stories decreases with ordinal
                                  position in the business process. It seems unlikely to me that the
                                  amount we need to learn decreases with ordinal position in the
                                  business process.

                                  Therefore it seems unlikely to me that priority is in same order as
                                  the position of the item in the business process.

                                  Ron Jeffries
                                  www.XProgramming.com
                                  www.xprogramming.com/blog
                                  You can observe a lot by watching. --Yogi Berra




                                  -- 
                                  Peter Stevens, CSM, CSPO, CSP
                                  www.scrum-breakfast.com
                                  tel: +41 44 586 6450 

                                • Tara Santmire
                                  I was unclear. We will deploy every two weeks to what we are calling a user experience test environment. The entire user community will be able to see, test,
                                  Message 16 of 28 , Jun 1, 2010
                                  • 0 Attachment

                                    I was unclear.  We will deploy every two weeks to what we are calling a user experience test environment.  The entire user community will be able to see, test, play and give feedback.  We just won’t deploy to the production environment until the whole process or at least one path through the process is complete. 

                                     

                                    Tara E. Santmire, CSM, PMP
                                    tara@...

                                     

                                    From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Roy Morien
                                    Sent: Monday, May 31, 2010 11:52 PM
                                    To: scrumdevelopment@yahoogroups.com
                                    Subject: RE: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                     

                                     

                                    I would like to make a quick comment on the matter of deploying.
                                     
                                    There is a significant risk in waiting to deploy until the whole product is finished. A 'big bang' deployment can come unstuck very easily, as we have seen many times. It is an all or nothing scenario, with the potential to be very disruptive.
                                     
                                    I do not see deployment of part of the system as necessarilly deploying into a production mode. There is a lot of value in deploying parts of the system as they are developed, assuming, of course, that the parts being deployed are a reasonably complete and exercisable sub-set. But even a single report can be usefully deployed.
                                     
                                    Doing it this way gives the users an opportunity to train on the software, to exercise the software, potentially finding bugs that always seem to occur when a user uses the software in a particular way, unforeseen previously. It also gives the opportunity for feedback about changes, and new requirements that using the software elicits.
                                     
                                    So there is a little-by-little flow of training, feedback, familiarisation etc. that is extremely valuable.
                                     
                                    Also, the mere fact that users see progress, manifested by usable parts being given to them regularly and frequently, keeps the project visible, giving users more confidence (and the developers) that things are on-track. The old feeling of 'we'll never see anything from this long, drawn-out process, that is invisible to us anyway' is overcome.
                                     
                                    Regards,
                                    Roy Morien
                                     


                                    To: scrumdevelopment@yahoogroups.com
                                    From: tara@...
                                    Date: Mon, 31 May 2010 20:07:41 -0400
                                    Subject: RE: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                     

                                    Ron – Thanks for taking the time to reply.

                                     

                                    On business value – I think that the PO is taking the point of view that she does not want to deploy until the entire process is deployable and so there is no business value in partial process so just do it in order.  Do you have any suggestions about how I might disabuse her of that notion?  Or might she be correct?  Even if she is wrong, if she is so engrained in thinking this through in terms of the process, might there be value in proceeding in this order?

                                     

                                    On risk – the team has reviewed the process and the associated user stories and their estimation of technical risk is that they are all in the same bin.  The team feels that they have done something fairly similar, for the various pieces of the process.  I can try and go back and elicit more granularity. 

                                     

                                    On amount to learn – you may be right.  I don’t have good ideas about how to elicit more information about prioritization in terms of “amount we need to learn”.  Do you have suggestions?  Even if you are correct, if the PO and users are so engrained in thinking this through in terms of the process, might there be value in proceeding in this order as this is the only way they can think through all the ramifications of decisions?

                                     

                                     

                                    Tara E. Santmire, CSM, PMP
                                    tara@...

                                     

                                    From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
                                    Sent: Monday, May 31, 2010 7:07 PM
                                    To: scrumdevelopment@yahoogroups.com
                                    Subject: Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                     

                                     

                                    Hello, Tara. On Monday, May 31, 2010, at 8:23:52 AM, you wrote:

                                    > The product owner wants to prioritize these stories in the same
                                    > order that they occur in the business process. I don't see any problems
                                    > with this, but I have a nagging feeling that I am missing something. Does
                                    > this seem like a reasonable way of prioritizing the stories? Does it have
                                    > any potential drawbacks?

                                    It seems unlikely to me that the business value of the stories is
                                    decreasing with ordinal position in the business process. It seems
                                    unlikely to me that the risk of the stories decreases with ordinal
                                    position in the business process. It seems unlikely to me that the
                                    amount we need to learn decreases with ordinal position in the
                                    business process.

                                    Therefore it seems unlikely to me that priority is in same order as
                                    the position of the item in the business process.

                                    Ron Jeffries
                                    www.XProgramming.com
                                    www.xprogramming.com/blog
                                    You can observe a lot by watching. --Yogi Berra

                                     

                                     


                                    Meet local singles online. Browse profiles for FREE!

                                  • Tara Santmire
                                    Well our first process is pretty complex. There are a number of different decision points. Some of those decision points kick off nice sequential processes.
                                    Message 17 of 28 , Jun 1, 2010
                                    • 0 Attachment

                                      Well our first process is pretty complex.  There are a number of different decision points.  Some of those decision points kick off nice sequential processes.  Some of them kickoff parallel processes  that never come back.  Some of them kickoff parallel processes that have to rejoin  and then kick off more stuff.  Sometimes there are circular review/revise until approval things.   In addition we expect to have somewhere on the order of 150 items moving through the process at any one time and there are specific actors at certain points and for many other things there are a group of actors and we have to know which actor from the group picked up the current step in the process.  So different people will be doing different things to the same item and/or different items at the same time. 

                                       

                                      The business value of the tool is to add transparency to the current process so that people can see anyone item moving through the process and know where it is and how long it is been there.  Also, knowledge/nags etc. when things are overdue.  Currently this is tracked in a spreadsheet and there are data problems and access problems etc.  The PO believes that the tool can’t deliver on this business value until it covers the whole process – replacing the spreadsheet.

                                       

                                      Tara E. Santmire, CSM, PMP
                                      tara@...

                                       

                                      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Roy Morien
                                      Sent: Tuesday, June 01, 2010 12:05 AM
                                      To: scrumdevelopment@yahoogroups.com
                                      Subject: RE: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                       

                                       

                                      Prioritising the Product Backlog to reflect the sequence of activities in the business process seems logical, on the face of it ... but ...
                                       
                                      Are business processes always 'sequential', such that one sub-process is always used before another specific one, and after another specific one? I would suggest not. Are they 'sequential' in that many users can be using each or any 'sub-process' dependant on what any other user is doing at that time? Again, I would suggest not. There is always some degree of randomness about who is doing what while someone else is doing th same, or something else. There is no 'sequence' obvious in this.
                                       
                                      The purpose of prioritising the Product Backlog is to ensure that high-value processes are delivered first, so that all that remains to be done at ay one time is of lower, or low value.
                                       
                                      Having said that, if tracing a path through the usual way of doing things provides a good framework for deciding on business value, then why not do it that way. But always keeping in mind that just because someone wants a report after they have done something else does not raise that report to a high level of priority, necessarilly.
                                       
                                      Regards,
                                      Roy Morien
                                       


                                      To: scrumdevelopment@yahoogroups.com
                                      From: peterstev@...
                                      Date: Tue, 1 Jun 2010 05:48:39 +0200
                                      Subject: Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                       

                                      Hi Tara,

                                      You have identified one way to think about the business process: Considering it as a sequence of steps to be executed one after the other. Is that the only way to think about it? Is it the best way?

                                      I once worked for a company which had a several processes to automate. The first such project I worked on, the program was conceived to implement its process step by step. This seemed logical at the time, but it made the software extremely difficult to test or change, and equally inflexible for the user.

                                      Later, I worked with two domain experts on the visioning of a similar project. We found that if we took an objected-oriented approach, the process became much simpler: The user would create a dossier, the former steps in the process became operations on the dossier, and a new 'make it so' operation (order) would complete the process. Once a dossier was created, it could be completed. The steps in the middle became optional (even though they remained important enough that most users in most cases would apply them). This made it possible for the P-O to prioritize the value of the operations, but also to add or remove alternatives in repesonse to changing priorities, time pressures, user/customer demands etc.

                                      For example: Most airline ticketing processes are sequential: 1) enter travel dates, number of passengers and departure and destination point 2) find flights 3) select flights 4) decide to order, 6) identify passengers 7) pay. What happens if your mother in law decides to join you on the trip? You have to start over. Why not just add her to the dossier? Why do you have to reenter the passenger data every time you want to consider a new alternative?

                                      If you were going to apply the dossier approach to airline ticketing, how would you do it? Which functions would you implement first? Maybe create dossier, pay for flight. Once these are implemented, you can potentially generate revenue. Next might be select alternative flights by price or by schedule, add spouse and kids. Now the customers can easily book the flight they want and bring the whole family. Probably adding your mother-in-law after the rest of the family has already booked a ticket won't be top on your priority list, but you may decide it's important later (especially if she offers to babysit ;-) ). Of course, this function will be competing with 'book rental car' and hotel booking functions which might have more value...

                                      If you were going to apply this approach to your application, how would you do it? What advantages and disadvantages would you have? Why are the advantages more important (or why aren't they)?

                                      Cheers,

                                      Peter

                                      On 01.06.10 02:07, Tara Santmire wrote:

                                       

                                       

                                      Ron – Thanks for taking the time to reply.

                                       

                                      On business value – I think that the PO is taking the point of view that she does not want to deploy until the entire process is deployable and so there is no business value in partial process so just do it in order.  Do you have any suggestions about how I might disabuse her of that notion?  Or might she be correct?  Even if she is wrong, if she is so engrained in thinking this through in terms of the process, might there be value in proceeding in this order?

                                       

                                      On risk – the team has reviewed the process and the associated user stories and their estimation of technical risk is that they are all in the same bin.  The team feels that they have done something fairly similar, for the various pieces of the process.  I can try and go back and elicit more granularity. 

                                       

                                      On amount to learn – you may be right.  I don’t have good ideas about how to elicit more information about prioritization in terms of “amount we need to learn”.  Do you have suggestions?  Even if you are correct, if the PO and users are so engrained in thinking this through in terms of the process, might there be value in proceeding in this order as this is the only way they can think through all the ramifications of decisions?

                                       

                                       

                                      Tara E. Santmire, CSM, PMP
                                      tara@...

                                       

                                      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
                                      Sent: Monday, May 31, 2010 7:07 PM
                                      To: scrumdevelopment@yahoogroups.com
                                      Subject: Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                       

                                       

                                      Hello, Tara. On Monday, May 31, 2010, at 8:23:52 AM, you wrote:

                                      > The product owner wants to prioritize these stories in the same
                                      > order that they occur in the business process. I don't see any problems
                                      > with this, but I have a nagging feeling that I am missing something. Does
                                      > this seem like a reasonable way of prioritizing the stories? Does it have
                                      > any potential drawbacks?

                                      It seems unlikely to me that the business value of the stories is
                                      decreasing with ordinal position in the business process. It seems
                                      unlikely to me that the risk of the stories decreases with ordinal
                                      position in the business process. It seems unlikely to me that the
                                      amount we need to learn decreases with ordinal position in the
                                      business process.

                                      Therefore it seems unlikely to me that priority is in same order as
                                      the position of the item in the business process.

                                      Ron Jeffries
                                      www.XProgramming.com
                                      www.xprogramming.com/blog
                                      You can observe a lot by watching. --Yogi Berra

                                       

                                      -- 
                                      Peter Stevens, CSM, CSPO, CSP
                                      www.scrum-breakfast.com
                                      tel: +41 44 586 6450 

                                       

                                       


                                      Find it on Domain.com.au Need a new place to live?

                                    • Roy Morien
                                      Hi Tara, Thanks for the information, which seems to concur with what I said. Obviously part of each process must be to be able to report the state and status
                                      Message 18 of 28 , Jun 1, 2010
                                      • 0 Attachment
                                        Hi Tara,
                                         
                                        Thanks for the information, which seems to concur with what I said. Obviously part of each process must be to be able to report the state and status of documents or 'items' as they move through the system. So this is part of the requirements, but still doesn't provide a particularly useful basis for prioritising the developent of these processes.
                                         
                                        But your applicaton does sound interesting.
                                         
                                        Regards,
                                        Roy Morien
                                         

                                        To: scrumdevelopment@yahoogroups.com
                                        From: tara@...
                                        Date: Tue, 1 Jun 2010 14:52:34 -0400
                                        Subject: RE: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                         

                                        Well our first process is pretty complex.  There are a number of different decision points.  Some of those decision points kick off nice sequential processes.  Some of them kickoff parallel processes  that never come back.  Some of them kickoff parallel processes that have to rejoin  and then kick off more stuff.  Sometimes there are circular review/revise until approval things.   In addition we expect to have somewhere on the order of 150 items moving through the process at any one time and there are specific actors at certain points and for many other things there are a group of actors and we have to know which actor from the group picked up the current step in the process.  So different people will be doing different things to the same item and/or different items at the same time. 

                                         

                                        The business value of the tool is to add transparency to the current process so that people can see anyone item moving through the process and know where it is and how long it is been there.  Also, knowledge/nags etc. when things are overdue.  Currently this is tracked in a spreadsheet and there are data problems and access problems etc.  The PO believes that the tool can’t deliver on this business value until it covers the whole process – replacing the spreadsheet.

                                         

                                        Tara E. Santmire, CSM, PMP
                                        tara@maresreach. net

                                         

                                        From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of Roy Morien
                                        Sent: Tuesday, June 01, 2010 12:05 AM
                                        To: scrumdevelopment@ yahoogroups. com
                                        Subject: RE: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                         

                                         

                                        Prioritising the Product Backlog to reflect the sequence of activities in the business process seems logical, on the face of it ... but ...
                                         
                                        Are business processes always 'sequential' , such that one sub-process is always used before another specific one, and after another specific one? I would suggest not. Are they 'sequential' in that many users can be using each or any 'sub-process' dependant on what any other user is doing at that time? Again, I would suggest not. There is always some degree of randomness about who is doing what while someone else is doing th same, or something else. There is no 'sequence' obvious in this.
                                         
                                        The purpose of prioritising the Product Backlog is to ensure that high-value processes are delivered first, so that all that remains to be done at ay one time is of lower, or low value.
                                         
                                        Having said that, if tracing a path through the usual way of doing things provides a good framework for deciding on business value, then why not do it that way. But always keeping in mind that just because someone wants a report after they have done something else does not raise that report to a high level of priority, necessarilly.
                                         
                                        Regards,
                                        Roy Morien
                                         

                                        To: scrumdevelopment@ yahoogroups. com
                                        From: peterstev@gmail. com
                                        Date: Tue, 1 Jun 2010 05:48:39 +0200
                                        Subject: Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                         

                                        Hi Tara,

                                        You have identified one way to think about the business process: Considering it as a sequence of steps to be executed one after the other. Is that the only way to think about it? Is it the best way?

                                        I once worked for a company which had a several processes to automate. The first such project I worked on, the program was conceived to implement its process step by step. This seemed logical at the time, but it made the software extremely difficult to test or change, and equally inflexible for the user.

                                        Later, I worked with two domain experts on the visioning of a similar project. We found that if we took an objected-oriented approach, the process became much simpler: The user would create a dossier, the former steps in the process became operations on the dossier, and a new 'make it so' operation (order) would complete the process. Once a dossier was created, it could be completed. The steps in the middle became optional (even though they remained important enough that most users in most cases would apply them). This made it possible for the P-O to prioritize the value of the operations, but also to add or remove alternatives in repesonse to changing priorities, time pressures, user/customer demands etc.

                                        For example: Most airline ticketing processes are sequential: 1) enter travel dates, number of passengers and departure and destination point 2) find flights 3) select flights 4) decide to order, 6) identify passengers 7) pay. What happens if your mother in law decides to join you on the trip? You have to start over. Why not just add her to the dossier? Why do you have to reenter the passenger data every time you want to consider a new alternative?

                                        If you were going to apply the dossier approach to airline ticketing, how would you do it? Which functions would you implement first? Maybe create dossier, pay for flight. Once these are implemented, you can potentially generate revenue. Next might be select alternative flights by price or by schedule, add spouse and kids. Now the customers can easily book the flight they want and bring the whole family. Probably adding your mother-in-law after the rest of the family has already booked a ticket won't be top on your priority list, but you may decide it's important later (especially if she offers to babysit ;-) ). Of course, this function will be competing with 'book rental car' and hotel booking functions which might have more value...

                                        If you were going to apply this approach to your application, how would you do it? What advantages and disadvantages would you have? Why are the advantages more important (or why aren't they)?

                                        Cheers,

                                        Peter

                                        On 01.06.10 02:07, Tara Santmire wrote:

                                         

                                         

                                        Ron – Thanks for taking the time to reply.

                                         

                                        On business value – I think that the PO is taking the point of view that she does not want to deploy until the entire process is deployable and so there is no business value in partial process so just do it in order.  Do you have any suggestions about how I might disabuse her of that notion?  Or might she be correct?  Even if she is wrong, if she is so engrained in thinking this through in terms of the process, might there be value in proceeding in this order?

                                         

                                        On risk – the team has reviewed the process and the associated user stories and their estimation of technical risk is that they are all in the same bin.  The team feels that they have done something fairly similar, for the various pieces of the process.  I can try and go back and elicit more granularity. 

                                         

                                        On amount to learn – you may be right.  I don’t have good ideas about how to elicit more information about prioritization in terms of “amount we need to learn”.  Do you have suggestions?  Even if you are correct, if the PO and users are so engrained in thinking this through in terms of the process, might there be value in proceeding in this order as this is the only way they can think through all the ramifications of decisions?

                                         

                                         

                                        Tara E. Santmire, CSM, PMP
                                        tara@maresreach. net

                                         

                                        From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelopment@yahoogroups. com] On Behalf Of Ron Jeffries
                                        Sent: Monday, May 31, 2010 7:07 PM
                                        To: scrumdevelopment@ yahoogroups. com
                                        Subject: Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                         

                                         

                                        Hello, Tara. On Monday, May 31, 2010, at 8:23:52 AM, you wrote:

                                        > The product owner wants to prioritize these stories in the same
                                        > order that they occur in the business process. I don't see any problems
                                        > with this, but I have a nagging feeling that I am missing something. Does
                                        > this seem like a reasonable way of prioritizing the stories? Does it have
                                        > any potential drawbacks?

                                        It seems unlikely to me that the business value of the stories is
                                        decreasing with ordinal position in the business process. It seems
                                        unlikely to me that the risk of the stories decreases with ordinal
                                        position in the business process. It seems unlikely to me that the
                                        amount we need to learn decreases with ordinal position in the
                                        business process.

                                        Therefore it seems unlikely to me that priority is in same order as
                                        the position of the item in the business process.

                                        Ron Jeffries
                                        www.XProgramming.com
                                        www.xprogramming.com/blog
                                        You can observe a lot by watching. --Yogi Berra

                                         

                                        -- 
                                        Peter Stevens, CSM, CSPO, CSP
                                        www.scrum-breakfast .com
                                        tel: +41 44 586 6450 

                                         

                                         


                                        Find it on Domain.com.au Need a new place to live?




                                        Find it at CarPoint.com.au New, Used, Demo, Dealer or Private?
                                      • Roy Morien
                                        OK ... and what do you see as the problem with delaying deployment into production in that way. Your user experience test environment does seem to be exactly
                                        Message 19 of 28 , Jun 1, 2010
                                        • 0 Attachment
                                          OK ... and what do you see as the problem with delaying deployment into production in that way.
                                           
                                          Your 'user experience test environment' does seem to be exactly what I was envisaging as a useful way to go, so you have got that covered.
                                           
                                          It seems to me that it is not always the case that parts of a system can be moved into production and be useful. This seems to be the case in your situation. Tracking an 'item' up to a certain point and being unable to go further because that part of the system has not been implemented does seem to come under this heading.
                                           
                                          Regards,
                                          Roy Morien
                                           

                                          To: scrumdevelopment@yahoogroups.com
                                          From: tara@...
                                          Date: Tue, 1 Jun 2010 14:35:25 -0400
                                          Subject: RE: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                           

                                          I was unclear.  We will deploy every two weeks to what we are calling a user experience test environment.  The entire user community will be able to see, test, play and give feedback.  We just won’t deploy to the production environment until the whole process or at least one path through the process is complete. 

                                           

                                          Tara E. Santmire, CSM, PMP
                                          tara@maresreach. net

                                           

                                          From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of Roy Morien
                                          Sent: Monday, May 31, 2010 11:52 PM
                                          To: scrumdevelopment@ yahoogroups. com
                                          Subject: RE: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                           

                                           

                                          I would like to make a quick comment on the matter of deploying.
                                           
                                          There is a significant risk in waiting to deploy until the whole product is finished. A 'big bang' deployment can come unstuck very easily, as we have seen many times. It is an all or nothing scenario, with the potential to be very disruptive.
                                           
                                          I do not see deployment of part of the system as necessarilly deploying into a production mode. There is a lot of value in deploying parts of the system as they are developed, assuming, of course, that the parts being deployed are a reasonably complete and exercisable sub-set. But even a single report can be usefully deployed.
                                           
                                          Doing it this way gives the users an opportunity to train on the software, to exercise the software, potentially finding bugs that always seem to occur when a user uses the software in a particular way, unforeseen previously. It also gives the opportunity for feedback about changes, and new requirements that using the software elicits.
                                           
                                          So there is a little-by-little flow of training, feedback, familiarisation etc. that is extremely valuable.
                                           
                                          Also, the mere fact that users see progress, manifested by usable parts being given to them regularly and frequently, keeps the project visible, giving users more confidence (and the developers) that things are on-track. The old feeling of 'we'll never see anything from this long, drawn-out process, that is invisible to us anyway' is overcome.
                                           
                                          Regards,
                                          Roy Morien
                                           

                                          To: scrumdevelopment@ yahoogroups. com
                                          From: tara@maresreach. net
                                          Date: Mon, 31 May 2010 20:07:41 -0400
                                          Subject: RE: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                           

                                          Ron – Thanks for taking the time to reply.

                                           

                                          On business value – I think that the PO is taking the point of view that she does not want to deploy until the entire process is deployable and so there is no business value in partial process so just do it in order.  Do you have any suggestions about how I might disabuse her of that notion?  Or might she be correct?  Even if she is wrong, if she is so engrained in thinking this through in terms of the process, might there be value in proceeding in this order?

                                           

                                          On risk – the team has reviewed the process and the associated user stories and their estimation of technical risk is that they are all in the same bin.  The team feels that they have done something fairly similar, for the various pieces of the process.  I can try and go back and elicit more granularity. 

                                           

                                          On amount to learn – you may be right.  I don’t have good ideas about how to elicit more information about prioritization in terms of “amount we need to learn”.  Do you have suggestions?  Even if you are correct, if the PO and users are so engrained in thinking this through in terms of the process, might there be value in proceeding in this order as this is the only way they can think through all the ramifications of decisions?

                                           

                                           

                                          Tara E. Santmire, CSM, PMP
                                          tara@maresreach. net

                                           

                                          From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of Ron Jeffries
                                          Sent: Monday, May 31, 2010 7:07 PM
                                          To: scrumdevelopment@ yahoogroups. com
                                          Subject: Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                           

                                           

                                          Hello, Tara. On Monday, May 31, 2010, at 8:23:52 AM, you wrote:

                                          > The product owner wants to prioritize these stories in the same
                                          > order that they occur in the business process. I don't see any problems
                                          > with this, but I have a nagging feeling that I am missing something. Does
                                          > this seem like a reasonable way of prioritizing the stories? Does it have
                                          > any potential drawbacks?

                                          It seems unlikely to me that the business value of the stories is
                                          decreasing with ordinal position in the business process. It seems
                                          unlikely to me that the risk of the stories decreases with ordinal
                                          position in the business process. It seems unlikely to me that the
                                          amount we need to learn decreases with ordinal position in the
                                          business process.

                                          Therefore it seems unlikely to me that priority is in same order as
                                          the position of the item in the business process.

                                          Ron Jeffries
                                          www.XProgramming. com
                                          www.xprogramming. com/blog
                                          You can observe a lot by watching. --Yogi Berra

                                           

                                           


                                          Meet local singles online. Browse profiles for FREE!




                                          Looking for a hot date? View photos of singles in your area!
                                        • Roy Morien
                                          Well, I was using value everywhere to mean business value. In para.4 I was just suggesting that if it was useful to follow the sequence of processing, using
                                          Message 20 of 28 , Jun 1, 2010
                                          • 0 Attachment
                                            Well, I was using 'value' everywhere to mean business value. In para.4 I was just suggesting that if it was useful to follow the sequence of processing, using that essentially as a proxy for prioritizing. This assumes that all processes are equal as far as business value goes, or at least there is little to differentiate them, so following the processing sequence is a good a way as any to organise things.
                                             
                                            Maybe not a very telling argument though, I must admit.
                                             
                                            Regards,
                                            Roy Morien
                                             
                                            > To: scrumdevelopment@yahoogroups.com
                                            > From: dan.rawsthorne@...
                                            > Date: Tue, 1 Jun 2010 03:43:05 -0700
                                            > Subject: Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation
                                            >
                                            > Interesting, Roy. Are you suggesting that the "value" described in
                                            > paragraph 3 is the same as "business value" described in paragraph 4? If
                                            > so, I disagree. I think the first is value to the Project, while the
                                            > second is value to the Client...
                                            >
                                            > I like the following thought experiments.
                                            > 1. Do we really want our team working on the highest-value business
                                            > processes when they are brand new, and don't have their sh*t together?
                                            > 2. How do technical dependencies play in this?
                                            > 3. How do personnel dependencies play in this?
                                            >
                                            > Just sayin' Dan ;-)
                                            >
                                            > Dan Rawsthorne, PhD, CST
                                            > Senior Trainer/Coach, CollabNet
                                            > drawsthorne@..., 425-269-8628
                                            >
                                            >
                                            >
                                            > Roy Morien wrote:
                                            > >
                                            > >
                                            > > Prioritising the Product Backlog to reflect the sequence of activities
                                            > > in the business process seems logical, on the face of it ... but ...
                                            > >
                                            > > Are business processes always 'sequential', such that one sub-process
                                            > > is always used before another specific one, and after another specific
                                            > > one? I would suggest not. Are they 'sequential' in that many users can
                                            > > be using each or any 'sub-process' dependant on what any other user is
                                            > > doing at that time? Again, I would suggest not. There is always some
                                            > > degree of randomness about who is doing what while someone else is
                                            > > doing th same, or something else. There is no 'sequence' obvious in this.
                                            > >
                                            > > The purpose of prioritising the Product Backlog is to ensure that
                                            > > high-value processes are delivered first, so that all that remains to
                                            > > be done at ay one time is of lower, or low value.
                                            > >
                                            > > Having said that, if tracing a path through the usual way of doing
                                            > > things provides a good framework for deciding on business value, then
                                            > > why not do it that way. But always keeping in mind that just because
                                            > > someone wants a report after they have done something else does not
                                            > > raise that report to a high level of priority, necessarilly.
                                            > >
                                            > > Regards,
                                            > > Roy Morien
                                            > >
                                            > >
                                            > > ------------------------------------------------------------------------
                                            > > To: scrumdevelopment@yahoogroups.com
                                            > > From: peterstev@...
                                            > > Date: Tue, 1 Jun 2010 05:48:39 +0200
                                            > > Subject: Re: [scrumdevelopment] Prioritization of Stories in Business
                                            > > Productivity Automation
                                            > >
                                            > >
                                            > > Hi Tara,
                                            > >
                                            > > You have identified one way to think about the business process:
                                            > > Considering it as a sequence of steps to be executed one after the
                                            > > other. Is that the only way to think about it? Is it the best way?
                                            > >
                                            > > I once worked for a company which had a several processes to automate.
                                            > > The first such project I worked on, the program was conceived to
                                            > > implement its process step by step. This seemed logical at the time,
                                            > > but it made the software extremely difficult to test or change, and
                                            > > equally inflexible for the user.
                                            > >
                                            > > Later, I worked with two domain experts on the visioning of a similar
                                            > > project. We found that if we took an objected-oriented approach, the
                                            > > process became much simpler: The user would create a dossier, the
                                            > > former steps in the process became operations on the dossier, and a
                                            > > new 'make it so' operation (order) would complete the process. Once a
                                            > > dossier was created, it could be completed. The steps in the middle
                                            > > became optional (even though they remained important enough that most
                                            > > users in most cases would apply them). This made it possible for the
                                            > > P-O to prioritize the value of the operations, but also to add or
                                            > > remove alternatives in repesonse to changing priorities, time
                                            > > pressures, user/customer demands etc.
                                            > >
                                            > > For example: Most airline ticketing processes are sequential: 1) enter
                                            > > travel dates, number of passengers and departure and destination point
                                            > > 2) find flights 3) select flights 4) decide to order, 6) identify
                                            > > passengers 7) pay. What happens if your mother in law decides to join
                                            > > you on the trip? You have to start over.. Why not just add her to the
                                            > > dossier? Why do you have to reenter the passenger data every time you
                                            > > want to consider a new alternative?
                                            > >
                                            > > If you were going to apply the dossier approach to airline ticketing,
                                            > > how would you do it? Which functions would you implement first? Maybe
                                            > > create dossier, pay for flight. Once these are implemented, you can
                                            > > potentially generate revenue. Next might be select alternative flights
                                            > > by price or by schedule, add spouse and kids. Now the customers can
                                            > > easily book the flight they want and bring the whole family. Probably
                                            > > adding your mother-in-law after the rest of the family has already
                                            > > booked a ticket won't be top on your priority list, but you may decide
                                            > > it's important later (especially if she offers to babysit ;-) ). Of
                                            > > course, this function will be competing with 'book rental car' and
                                            > > hotel booking functions which might have more value...
                                            > >
                                            > > If you were going to apply this approach to your application, how
                                            > > would you do it? What advantages and disadvantages would you have? Why
                                            > > are the advantages more important (or why aren't they)?
                                            > >
                                            > > Cheers,
                                            > >
                                            > > Peter
                                            > >
                                            > > On 01.06.10 02:07, Tara Santmire wrote:
                                            > >
                                            > >
                                            > >
                                            > >
                                            > > Ron – Thanks for taking the time to reply.
                                            > >
                                            > >
                                            > >
                                            > > On business value – I think that the PO is taking the point of
                                            > > view that she does not want to deploy until the entire process is
                                            > > deployable and so there is no business value in partial process so
                                            > > just do it in order. Do you have any suggestions about how I
                                            > > might disabuse her of that notion? Or might she be correct? Even
                                            > > if she is wrong, if she is so engrained in thinking this through
                                            > > in terms of the process, might there be value in proceeding in
                                            > > this order?
                                            > >
                                            > >
                                            > >
                                            > > On risk – the team has reviewed the process and the associated
                                            > > user stories and their estimation of technical risk is that they
                                            > > are all in the same bin. The team feels that they have done
                                            > > something fairly similar, for the various pieces of the process.
                                            > > I can try and go back and elicit more granularity.
                                            > >
                                            > >
                                            > >
                                            > > On amount to learn – you may be right. I don’t have good ideas
                                            > > about how to elicit more information about prioritization in terms
                                            > > of “amount we need to learn”. Do you have suggestions? Even if
                                            > > you are correct, if the PO and users are so engrained in thinking
                                            > > this through in terms of the process, might there be value in
                                            > > proceeding in this order as this is the only way they can think
                                            > > through all the ramifications of decisions?
                                            > >
                                            > >
                                            > >
                                            > >
                                            > >
                                            > > Tara E. Santmire, CSM, PMP
                                            > > tara@...
                                            > >
                                            > >
                                            > >
                                            > > *From:* scrumdevelopment@yahoogroups.com
                                            > > [mailto:scrumdevelopment@yahoogroups.com] *On Behalf Of *Ron Jeffries
                                            > > *Sent:* Monday, May 31, 2010 7:07 PM
                                            > > *To:* scrumdevelopment@yahoogroups.com
                                            > > *Subject:* Re: [scrumdevelopment] Prioritization of Stories in
                                            > > Business Productivity Automation
                                            > >
                                            > >
                                            > >
                                            > >
                                            > >
                                            > > Hello, Tara. On Monday, May 31, 2010, at 8:23:52 AM, you wrote:
                                            > >
                                            > > > The product owner wants to prioritize these stories in the same
                                            > > > order that they occur in the business process. I don't see any
                                            > > problems
                                            > > > with this, but I have a nagging feeling that I am missing
                                            > > something. Does
                                            > > > this seem like a reasonable way of prioritizing the stories?
                                            > > Does it have
                                            > > > any potential drawbacks?
                                            > >
                                            > > It seems unlikely to me that the business value of the stories is
                                            > > decreasing with ordinal position in the business process. It seems
                                            > > unlikely to me that the risk of the stories decreases with ordinal
                                            > > position in the business process. It seems unlikely to me that the
                                            > > amount we need to learn decreases with ordinal position in the
                                            > > business process.
                                            > >
                                            > > Therefore it seems unlikely to me that priority is in same order as
                                            > > the position of the item in the business process.
                                            > >
                                            > > Ron Jeffries
                                            > > www.XProgramming <http://www.xprogramming/>.com
                                            > > www.xprogramming <http://www.xprogramming/>.com/blog
                                            > > You can observe a lot by watching. --Yogi Berra
                                            > >
                                            > >
                                            > >
                                            > > --
                                            > > Peter Stevens, CSM, CSPO, CSP
                                            > > www.scrum-breakfast.com <http://www.scrum-breakfast..com/>
                                            > > tel: +41 44 586 6450
                                            > >
                                            > >
                                            > >
                                            > > ------------------------------------------------------------------------
                                            > > Find it on Domain.com.au Need a new place to live?
                                            > > <http://clk.atdmt.com/NMN/go/157631292/direct/01/>
                                            > >
                                            > >
                                            > >
                                            > >
                                            > >
                                            > >
                                            > > =======
                                            > > Email scanned by PC Tools - No viruses or spyware found.
                                            > > (Email Guard: 7.0.0.18, Virus/Spyware Database: 6.15120)
                                            > > http://www.pctools.com
                                            > > <http://www.pctools.com/?cclick=EmailFooterClean_51>
                                            > > =======
                                            >
                                            >
                                            > ------------------------------------
                                            >
                                            > To Post a message, send it to: scrumdevelopment@...
                                            > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                                            >
                                            > <*> To visit your group on the web, go to:
                                            > http://groups.yahoo.com/group/scrumdevelopment/
                                            >
                                            > <*> Your email settings:
                                            > Individual Email | Traditional
                                            >
                                            > <*> To change settings online go to:
                                            > http://groups.yahoo.com/group/scrumdevelopment/join
                                            > (Yahoo! ID required)
                                            >
                                            > <*> To change settings via email:
                                            > scrumdevelopment-digest@yahoogroups.com
                                            > scrumdevelopment-fullfeatured@yahoogroups.com
                                            >
                                            > <*> To unsubscribe from this group, send an email to:
                                            > scrumdevelopment-unsubscribe@yahoogroups.com
                                            >
                                            > <*> Your use of Yahoo! Groups is subject to:
                                            > http://docs.yahoo.com/info/terms/
                                            >


                                            Find it at CarPoint.com.au New, Used, Demo, Dealer or Private?
                                          • William Wake
                                            ... process so that ... and how ... overdue. Currently this ... problems etc. The PO ... covers the whole process ... I m imagining that some part of the
                                            Message 21 of 28 , Jun 1, 2010
                                            • 0 Attachment

                                              > The business value of the tool is to add transparency to the current process so that 

                                              > people can see anyone item moving through the process and know where it is and how 

                                              > long it is been there.  Also, knowledge/nags etc. when things are overdue.  Currently this 

                                              > is tracked in a spreadsheet and there are data problems and access problems etc.  The PO 

                                              > believes that the tool can’t deliver on this business value until it covers the whole process

                                              >  – replacing the spreadsheet.

                                              I'm imagining that some part of the process "listens" for status from items as they change states, owners, etc. Would it be possible to use the spreadsheet as an input to that? The early value would be "people can monitor using the new page." While the spreadsheet itself would be still have issues around multiple writers, there would only be a single reader. Then, as each process (or partial process) is added for automatic monitoring, it would no longer be manually tracked in the spreadsheet. Once all were converted, there'd be no more manual updates and no more spreadsheet. 

                                              This would let you start deploying right away rather than wait till everything is converted.

                                              (There are variations you could do (e.g., writing spreadsheet from the new system) but I think it'd be better to get the new page visible sooner.)

                                              --Bill Wake

                                              On Tue, Jun 1, 2010 at 2:52 PM, Tara Santmire <tara@...> wrote:
                                               

                                              Well our first process is pretty complex.  There are a number of different decision points.  Some of those decision points kick off nice sequential processes.  Some of them kickoff parallel processes  that never come back.  Some of them kickoff parallel processes that have to rejoin  and then kick off more stuff.  Sometimes there are circular review/revise until approval things.   In addition we expect to have somewhere on the order of 150 items moving through the process at any one time and there are specific actors at certain points and for many other things there are a group of actors and we have to know which actor from the group picked up the current step in the process.  So different people will be doing different things to the same item and/or different items at the same time. 

                                               

                                              The business value of the tool is to add transparency to the current process so that people can see anyone item moving through the process and know where it is and how long it is been there.  Also, knowledge/nags etc. when things are overdue.  Currently this is tracked in a spreadsheet and there are data problems and access problems etc.  The PO believes that the tool can’t deliver on this business value until it covers the whole process – replacing the spreadsheet.

                                               

                                              Tara E. Santmire, CSM, PMP
                                              ta

                                            • Tara Santmire
                                              I don t see a problem with the delay into production. But it means that the PO is not saying I need feature X in production first and then feature Y and then
                                              Message 22 of 28 , Jun 2, 2010
                                              • 0 Attachment

                                                I don’t see a problem with the delay into production.  But it means that the PO is not saying I need feature X in production first and then feature Y and then feature Q.  I don’t get PO prioritization of the user stories.  I understand the rationale from the PO and agree with your comment below.  It just makes the prioritization something that takes more thought.  I really appreciate the comments from you and others here.

                                                 

                                                Tara E. Santmire, CSM, PMP
                                                tara@...

                                                 

                                                From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Roy Morien
                                                Sent: Tuesday, June 01, 2010 10:28 PM
                                                To: scrumdevelopment@yahoogroups.com
                                                Subject: RE: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                                 

                                                 

                                                OK ... and what do you see as the problem with delaying deployment into production in that way.
                                                 
                                                Your 'user experience test environment' does seem to be exactly what I was envisaging as a useful way to go, so you have got that covered.
                                                 
                                                It seems to me that it is not always the case that parts of a system can be moved into production and be useful. This seems to be the case in your situation. Tracking an 'item' up to a certain point and being unable to go further because that part of the system has not been implemented does seem to come under this heading.
                                                 
                                                Regards,
                                                Roy Morien
                                                 


                                                To: scrumdevelopment@yahoogroups.com
                                                From: tara@...
                                                Date: Tue, 1 Jun 2010 14:35:25 -0400
                                                Subject: RE: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                                 

                                                I was unclear.  We will deploy every two weeks to what we are calling a user experience test environment.  The entire user community will be able to see, test, play and give feedback.  We just won’t deploy to the production environment until the whole process or at least one path through the process is complete. 

                                                 

                                                Tara E. Santmire, CSM, PMP
                                                tara@...

                                                 

                                                From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Roy Morien
                                                Sent: Monday, May 31, 2010 11:52 PM
                                                To: scrumdevelopment@yahoogroups.com
                                                Subject: RE: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                                 

                                                 

                                                I would like to make a quick comment on the matter of deploying.
                                                 
                                                There is a significant risk in waiting to deploy until the whole product is finished. A 'big bang' deployment can come unstuck very easily, as we have seen many times. It is an all or nothing scenario, with the potential to be very disruptive.
                                                 
                                                I do not see deployment of part of the system as necessarilly deploying into a production mode. There is a lot of value in deploying parts of the system as they are developed, assuming, of course, that the parts being deployed are a reasonably complete and exercisable sub-set. But even a single report can be usefully deployed.
                                                 
                                                Doing it this way gives the users an opportunity to train on the software, to exercise the software, potentially finding bugs that always seem to occur when a user uses the software in a particular way, unforeseen previously. It also gives the opportunity for feedback about changes, and new requirements that using the software elicits.
                                                 
                                                So there is a little-by-little flow of training, feedback, familiarisation etc. that is extremely valuable.
                                                 
                                                Also, the mere fact that users see progress, manifested by usable parts being given to them regularly and frequently, keeps the project visible, giving users more confidence (and the developers) that things are on-track. The old feeling of 'we'll never see anything from this long, drawn-out process, that is invisible to us anyway' is overcome.
                                                 
                                                Regards,
                                                Roy Morien
                                                 


                                                To: scrumdevelopment@yahoogroups.com
                                                From: tara@...
                                                Date: Mon, 31 May 2010 20:07:41 -0400
                                                Subject: RE: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                                 

                                                Ron – Thanks for taking the time to reply.

                                                 

                                                On business value – I think that the PO is taking the point of view that she does not want to deploy until the entire process is deployable and so there is no business value in partial process so just do it in order.  Do you have any suggestions about how I might disabuse her of that notion?  Or might she be correct?  Even if she is wrong, if she is so engrained in thinking this through in terms of the process, might there be value in proceeding in this order?

                                                 

                                                On risk – the team has reviewed the process and the associated user stories and their estimation of technical risk is that they are all in the same bin.  The team feels that they have done something fairly similar, for the various pieces of the process.  I can try and go back and elicit more granularity. 

                                                 

                                                On amount to learn – you may be right.  I don’t have good ideas about how to elicit more information about prioritization in terms of “amount we need to learn”.  Do you have suggestions?  Even if you are correct, if the PO and users are so engrained in thinking this through in terms of the process, might there be value in proceeding in this order as this is the only way they can think through all the ramifications of decisions?

                                                 

                                                 

                                                Tara E. Santmire, CSM, PMP
                                                tara@...

                                                 

                                                From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
                                                Sent: Monday, May 31, 2010 7:07 PM
                                                To: scrumdevelopment@yahoogroups.com
                                                Subject: Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                                 

                                                 

                                                Hello, Tara. On Monday, May 31, 2010, at 8:23:52 AM, you wrote:

                                                > The product owner wants to prioritize these stories in the same
                                                > order that they occur in the business process. I don't see any problems
                                                > with this, but I have a nagging feeling that I am missing something. Does
                                                > this seem like a reasonable way of prioritizing the stories? Does it have
                                                > any potential drawbacks?

                                                It seems unlikely to me that the business value of the stories is
                                                decreasing with ordinal position in the business process. It seems
                                                unlikely to me that the risk of the stories decreases with ordinal
                                                position in the business process. It seems unlikely to me that the
                                                amount we need to learn decreases with ordinal position in the
                                                business process.

                                                Therefore it seems unlikely to me that priority is in same order as
                                                the position of the item in the business process.

                                                Ron Jeffries
                                                www.XProgramming.com
                                                www.xprogramming.com/blog
                                                You can observe a lot by watching. --Yogi Berra

                                                 

                                                 


                                                Meet local singles online. Browse profiles for FREE!

                                                 

                                                 


                                                Looking for a hot date? View photos of singles in your area!

                                              • Tara Santmire
                                                Thanks Bill for taking the time to reply. That is a thought. We could put up an editable data grid and the system could put in data where it could and people
                                                Message 23 of 28 , Jun 2, 2010
                                                • 0 Attachment

                                                  Thanks Bill for taking the time to reply.

                                                   

                                                  That is a thought.  We could put up an editable data grid and the system could put in data where it could and people could fill in the rest.  Every time we essentially add  a step in the process we move a column from editable to non-editable. 

                                                   

                                                  Tara E. Santmire, CSM, PMP
                                                  tara@...

                                                   

                                                  From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of William Wake
                                                  Sent: Tuesday, June 01, 2010 10:51 PM
                                                  To: scrumdevelopment@yahoogroups.com
                                                  Subject: Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                                   

                                                   

                                                  > The business value of the tool is to add transparency to the current process so that 

                                                  > people can see anyone item moving through the process and know where it is and how 

                                                  > long it is been there.  Also, knowledge/nags etc. when things are overdue.  Currently this 

                                                  > is tracked in a spreadsheet and there are data problems and access problems etc.  The PO 

                                                  > believes that the tool can’t deliver on this business value until it covers the whole process

                                                  >  – replacing the spreadsheet.

                                                  I'm imagining that some part of the process "listens" for status from items as they change states, owners, etc. Would it be possible to use the spreadsheet as an input to that? The early value would be "people can monitor using the new page." While the spreadsheet itself would be still have issues around multiple writers, there would only be a single reader. Then, as each process (or partial process) is added for automatic monitoring, it would no longer be manually tracked in the spreadsheet. Once all were converted, there'd be no more manual updates and no more spreadsheet. 

                                                   

                                                  This would let you start deploying right away rather than wait till everything is converted.

                                                   

                                                  (There are variations you could do (e.g., writing spreadsheet from the new system) but I think it'd be better to get the new page visible sooner.)

                                                   

                                                  --Bill Wake

                                                   

                                                  On Tue, Jun 1, 2010 at 2:52 PM, Tara Santmire <tara@...> wrote:

                                                   

                                                  Well our first process is pretty complex.  There are a number of different decision points.  Some of those decision points kick off nice sequential processes.  Some of them kickoff parallel processes  that never come back.  Some of them kickoff parallel processes that have to rejoin  and then kick off more stuff.  Sometimes there are circular review/revise until approval things.   In addition we expect to have somewhere on the order of 150 items moving through the process at any one time and there are specific actors at certain points and for many other things there are a group of actors and we have to know which actor from the group picked up the current step in the process.  So different people will be doing different things to the same item and/or different items at the same time. 

                                                   

                                                  The business value of the tool is to add transparency to the current process so that people can see anyone item moving through the process and know where it is and how long it is been there.  Also, knowledge/nags etc. when things are overdue.  Currently this is tracked in a spreadsheet and there are data problems and access problems etc.  The PO believes that the tool can’t deliver on this business value until it covers the whole process – replacing the spreadsheet.

                                                   

                                                  Tara E. Santmire, CSM, PMP
                                                  ta

                                                • Peter Stevens (cal)
                                                  On 01.06.10 20:30, Tara Santmire wrote: Peter - Thanks for taking the time to reply. The dossier approach is interesting and I will discuss with the team. I
                                                  Message 24 of 28 , Jun 2, 2010
                                                  • 0 Attachment
                                                    On 01.06.10 20:30, Tara Santmire wrote:  

                                                    Peter  - Thanks for taking the time to reply.  The dossier approach is interesting and I will discuss with the team.  I wonder though how much it saves you given the object oriented nature of programming with today’s workflow engines. 

                                                    Hi Tara,

                                                    Does it automatically follow from using object oriented tools that you get an object oriented UI? Hmm, I don't know the answer to that question. In our case it did not, but we were using Java, not an engine.

                                                    In the second project, where I did the visioning work, we looked at the flow of an order from the first input from the customer to the final billing. A classical value flow diagram did not work for exactly the reasons you described: too much variability in the route and times for each step. So we extended the value flow diagram in to a four track diagram. Each track represented a major actor -- "us" (in quotes, becase 'we' means my customer), suppliers, customers, customers' customers -- and the x axis represented the sequence of events.

                                                    This helped us identify where the process was complex, error prone and in need of optimization. We were also able to identify several points where 'we' had delivered value to the customer, but not yet earned revenue. When the final step came, it was clear why customers were saying no - they could do the last step themselves for less money than we could, because we were charging for the whole process in the last step. This led to some fundamental rethinking of the process, what's a service, what get's billed when, etc, so the business can be more effective.

                                                    The dossier approach meant that the customer could do simple things quickly. Almost from the point of creation onward, a 'make it so' command, could cause the final order, but also individual value added steps can be performed (and potentially charged), repeatedly if necessary, until the dossier is in the desired state.

                                                    Cheers,

                                                    Peter

                                                    -- 
                                                    Peter Stevens, CSM, CSPO, CSP
                                                    Independent Scrum Trainer and Coach
                                                    Sierra-Charlie Consulting | Zurich | Switzerland
                                                    
                                                    Member of DasScrumTeam.de
                                                    
                                                    blog:  http://scrum-breakfast.com
                                                    tel:   +41 44 586 6450 
                                                    cell:  +41 79 422 6722
                                                    skype: peterstev
                                                  • JackM
                                                    Risk does not have to be purely technical. There may be usability risk, stuff to do with layout etc. This is just one other risk that comes to mind. What about
                                                    Message 25 of 28 , Jun 2, 2010
                                                    • 0 Attachment
                                                      Risk does not have to be purely technical. There may be usability risk, stuff to do with layout etc. This is just one other risk that comes to mind. What about performance, cross browser related issues to for certain components etc.

                                                      Important to do the things first that you can learn the most from. I am sure that the PO can do better than to choose just the order in which the process is invoked. But it's not wrong just might not be optimal

                                                      Nice advice from the others.

                                                      Jack
                                                      blog.agilebuddy.com
                                                      www.agilebuddy.com
                                                      twitter.com/agilebuddy

                                                      --- In scrumdevelopment@yahoogroups.com, "Peter Stevens (calendar)" <peterstev@...> wrote:
                                                      >
                                                      > Hi Tara,
                                                      >
                                                      > You have identified one way to think about the business process:
                                                      > Considering it as a sequence of steps to be executed one after the
                                                      > other. Is that the only way to think about it? Is it the best way?
                                                      >
                                                      > I once worked for a company which had a several processes to automate.
                                                      > The first such project I worked on, the program was conceived to
                                                      > implement its process step by step. This seemed logical at the time, but
                                                      > it made the software extremely difficult to test or change, and equally
                                                      > inflexible for the user.
                                                      >
                                                      > Later, I worked with two domain experts on the visioning of a similar
                                                      > project. We found that if we took an objected-oriented approach, the
                                                      > process became much simpler: The user would create a dossier, the former
                                                      > steps in the process became operations on the dossier, and a new 'make
                                                      > it so' operation (order) would complete the process. Once a dossier was
                                                      > created, it could be completed. The steps in the middle became optional
                                                      > (even though they remained important enough that most users in most
                                                      > cases would apply them). This made it possible for the P-O to prioritize
                                                      > the value of the operations, but also to add or remove alternatives in
                                                      > repesonse to changing priorities, time pressures, user/customer demands etc.
                                                      >
                                                      > For example: Most airline ticketing processes are sequential: 1) enter
                                                      > travel dates, number of passengers and departure and destination point
                                                      > 2) find flights 3) select flights 4) decide to order, 6) identify
                                                      > passengers 7) pay. What happens if your mother in law decides to join
                                                      > you on the trip? You have to start over. Why not just add her to the
                                                      > dossier? Why do you have to reenter the passenger data every time you
                                                      > want to consider a new alternative?
                                                      >
                                                      > If you were going to apply the dossier approach to airline ticketing,
                                                      > how would you do it? Which functions would you implement first? Maybe
                                                      > create dossier, pay for flight. Once these are implemented, you can
                                                      > potentially generate revenue. Next might be select alternative flights
                                                      > by price or by schedule, add spouse and kids. Now the customers can
                                                      > easily book the flight they want and bring the whole family. Probably
                                                      > adding your mother-in-law after the rest of the family has already
                                                      > booked a ticket won't be top on your priority list, but you may decide
                                                      > it's important later (especially if she offers to babysit ;-) ). Of
                                                      > course, this function will be competing with 'book rental car' and hotel
                                                      > booking functions which might have more value...
                                                      >
                                                      > If you were going to apply this approach to your application, how would
                                                      > you do it? What advantages and disadvantages would you have? Why are the
                                                      > advantages more important (or why aren't they)?
                                                      >
                                                      > Cheers,
                                                      >
                                                      > Peter
                                                      >
                                                      > On 01.06.10 02:07, Tara Santmire wrote:
                                                      > >
                                                      > > Ron -- Thanks for taking the time to reply.
                                                      > >
                                                      > > On business value -- I think that the PO is taking the point of view
                                                      > > that she does not want to deploy until the entire process is
                                                      > > deployable and so there is no business value in partial process so
                                                      > > just do it in order. Do you have any suggestions about how I might
                                                      > > disabuse her of that notion? Or might she be correct? Even if she is
                                                      > > wrong, if she is so engrained in thinking this through in terms of the
                                                      > > process, might there be value in proceeding in this order?
                                                      > >
                                                      > > On risk -- the team has reviewed the process and the associated user
                                                      > > stories and their estimation of technical risk is that they are all in
                                                      > > the same bin. The team feels that they have done something fairly
                                                      > > similar, for the various pieces of the process. I can try and go back
                                                      > > and elicit more granularity.
                                                      > >
                                                      > > On amount to learn -- you may be right. I don't have good ideas about
                                                      > > how to elicit more information about prioritization in terms of
                                                      > > "amount we need to learn". Do you have suggestions? Even if you are
                                                      > > correct, if the PO and users are so engrained in thinking this through
                                                      > > in terms of the process, might there be value in proceeding in this
                                                      > > order as this is the only way they can think through all the
                                                      > > ramifications of decisions?
                                                      > >
                                                      > > Tara E. Santmire, CSM, PMP
                                                      > > tara@...
                                                      > >
                                                      > > *From:* scrumdevelopment@yahoogroups.com
                                                      > > [mailto:scrumdevelopment@yahoogroups.com] *On Behalf Of *Ron Jeffries
                                                      > > *Sent:* Monday, May 31, 2010 7:07 PM
                                                      > > *To:* scrumdevelopment@yahoogroups.com
                                                      > > *Subject:* Re: [scrumdevelopment] Prioritization of Stories in
                                                      > > Business Productivity Automation
                                                      > >
                                                      > > Hello, Tara. On Monday, May 31, 2010, at 8:23:52 AM, you wrote:
                                                      > >
                                                      > > > The product owner wants to prioritize these stories in the same
                                                      > > > order that they occur in the business process. I don't see any problems
                                                      > > > with this, but I have a nagging feeling that I am missing something.
                                                      > > Does
                                                      > > > this seem like a reasonable way of prioritizing the stories? Does it
                                                      > > have
                                                      > > > any potential drawbacks?
                                                      > >
                                                      > > It seems unlikely to me that the business value of the stories is
                                                      > > decreasing with ordinal position in the business process. It seems
                                                      > > unlikely to me that the risk of the stories decreases with ordinal
                                                      > > position in the business process. It seems unlikely to me that the
                                                      > > amount we need to learn decreases with ordinal position in the
                                                      > > business process.
                                                      > >
                                                      > > Therefore it seems unlikely to me that priority is in same order as
                                                      > > the position of the item in the business process.
                                                      > >
                                                      > > Ron Jeffries
                                                      > > www.XProgramming.com
                                                      > > www.xprogramming.com/blog
                                                      > > You can observe a lot by watching. --Yogi Berra
                                                      > >
                                                      > >
                                                      >
                                                      >
                                                      > --
                                                      > Peter Stevens, CSM, CSPO, CSP
                                                      > www.scrum-breakfast.com
                                                      > tel: +41 44 586 6450
                                                      >
                                                    • William Wake
                                                      ... Right. This gives you a reason for early deployment and a basis to prioritize stories for the other steps - on the amount of manual work they eliminate.
                                                      Message 26 of 28 , Jun 2, 2010
                                                      • 0 Attachment
                                                        On Wed, Jun 2, 2010 at 11:56 AM, Tara Santmire <tara@...> wrote:

                                                        That is a thought.  We could put up an editable data grid and the system could put in data where it could and people could fill in the rest.  Every time we essentially add  a step in the process we move a column from editable to non-editable. 


                                                        Right. This gives you a reason for early deployment and a basis to prioritize stories for the other steps - on the amount of manual work they eliminate. 

                                                         

                                                        Tara E. Santmire, CSM, PMP
                                                        tara@...


                                                      • Tara Santmire
                                                        “amount of manual work they eliminate” - now why didn’t I think of that Thank you!!! Tara E. Santmire, CSM, PMP tara@maresreach.net From:
                                                        Message 27 of 28 , Jun 3, 2010
                                                        • 0 Attachment

                                                          “amount of manual work they eliminate”  - now why didn’t I think of that

                                                           

                                                          Thank you!!!

                                                           

                                                          Tara E. Santmire, CSM, PMP
                                                          tara@...

                                                           

                                                          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of William Wake
                                                          Sent: Wednesday, June 02, 2010 9:55 PM
                                                          To: scrumdevelopment@yahoogroups.com
                                                          Subject: Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                                           

                                                           

                                                          On Wed, Jun 2, 2010 at 11:56 AM, Tara Santmire <tara@...> wrote:

                                                          That is a thought.  We could put up an editable data grid and the system could put in data where it could and people could fill in the rest.  Every time we essentially add  a step in the process we move a column from editable to non-editable. 

                                                           

                                                          Right. This gives you a reason for early deployment and a basis to prioritize stories for the other steps - on the amount of manual work they eliminate. 

                                                           

                                                          Tara E. Santmire, CSM, PMP

                                                          tara@...

                                                           

                                                        • Tara Santmire
                                                          Peter, I don t think that it automatically follows that you get an object oriented UI from an object oriented tool. However, if you carefully craft the
                                                          Message 28 of 28 , Jun 3, 2010
                                                          • 0 Attachment

                                                            Peter,

                                                             

                                                            I don’t think that it automatically follows that you get an object oriented UI from an object oriented tool.  However, if you carefully craft the business objects, then it should be possible to make an object oriented UI without too much difficulty.  Then you can use a workflow engine to move those objects around as needed.  The workflow itself becomes a set of wrappers around the objects that moves the objects from one state to another, tracks state, and tracks who and when. 

                                                             

                                                            The process at hand for our project is different in that there really are no optional steps.  There are decision points which tell you which path to go down, but once a path is selected, there are no optional items.  The complicated bit is that we have an item to move through the process (object x),  in one path to move object x forward seven parallel processes all with their own objects have to move forward four of those parallel things come together to create yet another object which gets shoved down a process.  The other three processes (with their own objects) just go to their own completions.  Critical for us that we correctly create the data model to support this and the business object model as well.  Then we have the presentation layer where we have widely varying requests from different parts of the user community. 

                                                             

                                                            Interestingly enough this set of processes is already highly optimized.  People have been doing it for a while very successfully,  the problem is that because it is so complicated it is very labor intensive to do correctly without losing things.  The goal here is to actually reduce the number of people necessary to keep all of the different objects moving through the system and increase transparency into where things are at any given time.

                                                             

                                                            Regards,

                                                            Tara

                                                             

                                                            Tara E. Santmire, CSM, PMP
                                                            tara@...

                                                             

                                                            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Peter Stevens (cal)
                                                            Sent: Wednesday, June 02, 2010 12:56 PM
                                                            To: scrumdevelopment@yahoogroups.com
                                                            Subject: Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

                                                             

                                                             

                                                            On 01.06.10 20:30, Tara Santmire wrote:

                                                             

                                                            Peter  - Thanks for taking the time to reply.  The dossier approach is interesting and I will discuss with the team.  I wonder though how much it saves you given the object oriented nature of programming with today’s workflow engines. 

                                                            Hi Tara,

                                                            Does it automatically follow from using object oriented tools that you get an object oriented UI? Hmm, I don't know the answer to that question. In our case it did not, but we were using Java, not an engine.

                                                            In the second project, where I did the visioning work, we looked at the flow of an order from the first input from the customer to the final billing. A classical value flow diagram did not work for exactly the reasons you described: too much variability in the route and times for each step. So we extended the value flow diagram in to a four track diagram. Each track represented a major actor -- "us" (in quotes, becase 'we' means my customer), suppliers, customers, customers' customers -- and the x axis represented the sequence of events.

                                                            This helped us identify where the process was complex, error prone and in need of optimization. We were also able to identify several points where 'we' had delivered value to the customer, but not yet earned revenue. When the final step came, it was clear why customers were saying no - they could do the last step themselves for less money than we could, because we were charging for the whole process in the last step. This led to some fundamental rethinking of the process, what's a service, what get's billed when, etc, so the business can be more effective.

                                                            The dossier approach meant that the customer could do simple things quickly. Almost from the point of creation onward, a 'make it so' command, could cause the final order, but also individual value added steps can be performed (and potentially charged), repeatedly if necessary, until the dossier is in the desired state.

                                                            Cheers,

                                                            Peter


                                                            -- 
                                                            Peter Stevens, CSM, CSPO, CSP
                                                            Independent Scrum Trainer and Coach
                                                            Sierra-Charlie Consulting | Zurich | Switzerland
                                                              
                                                            Member of DasScrumTeam.de
                                                              
                                                            blog:  http://scrum-breakfast.com
                                                            tel:   +41 44 586 6450 
                                                            cell:  +41 79 422 6722
                                                            skype: peterstev

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