Re: Prioritization of Stories in Business Productivity Automation
- 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.
--- In email@example.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)?
> 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:* firstname.lastname@example.org
> > [mailto:email@example.com] *On Behalf Of *Ron Jeffries
> > *Sent:* Monday, May 31, 2010 7:07 PM
> > *To:* firstname.lastname@example.org
> > *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
> tel: +41 44 586 6450
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.
“amount of manual work they eliminate” - now why didn’t I think of that
Tara E. Santmire, CSM, PMP
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.
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.
Tara E. Santmire, CSM, PMP
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.
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.
Peter Stevens, CSM, CSPO, CSP
Independent Scrum Trainer and Coach
Sierra-Charlie Consulting | Zurich | Switzerland
Member of DasScrumTeam.de
tel: +41 44 586 6450
cell: +41 79 422 6722