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

47061RE: [scrumdevelopment] Prioritization of Stories in Business Productivity Automation

Expand Messages
  • Roy Morien
    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?
    • Show all 28 messages in this topic