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

47050Re: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

Expand Messages
  • Dan Rawsthorne
    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>
      > =======
    • Show all 28 messages in this topic