RE: [epf-dev] Prioritizing requirements

[Ricardo Balduino <balduino@xxxxxxxxxx>]

I agree that we have a good coverage
on prioritization of work - all prioritization is done in a collaborative
way in OpenUP. My concern is that explicitly assigning a task to Stakeholder
saying "stakeholders prioritize requirements" could potentially
decrease the visibility of this collaboration.  Besides, there is
the business priority and architecturally significance that should count
when prioritizing work to be performed in an iteration.

We may need some rewording here and
there, and perhaps a guideline explaining how prioritization of work happens
in OpenUP (the "aha moment" Brian mentions).

Cheers,

Ricardo Balduino
Senior Software Engineer

IBM Rational Software (www.ibm.com/rational)
EPF Committer (www.eclipse.org/epf)

Mark.Dickson@xxxxxxxxx
Sent by: epf-dev-bounces@xxxxxxxxxxx

03/13/2007 07:38 AM

Please respond to
Eclipse Process Framework Project Developers List        <epf-dev@xxxxxxxxxxx>

To	Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
cc
Subject	RE: [epf-dev] Prioritizing requirements

Ben

I agree that we need to be explicit about requirements prioritization.

A guideline on this topic that distils the approach into a single place
would be very useful. The current distribution of the various contributing
steps seems reasonable, i.e.

   The Analyst role captures (not decides) the initial prioritization
of
   features against the Vision from the Stakeholder
   The Architect role calls out the subset of architecturally significant
   requirements that need to be built to produce a stable architecture
   The PM role captures (not decides) the overall priority of the
known
   requirements as determined by the team (including - and especially
- the
   Stakeholder?) during Plan the Project
   The PM role facilitates (not decides) the re-appraisal of priorities
by
   the team and the work items that need to be delivered to meet them
   during Plan the Iteration

How does that sound?

cheers

Mark

Mark Dickson
Executive Consultant
EAS Practice
m 0780 1917480
w www.xansa.com
e mark.dickson@xxxxxxxxx


                    
                     
                     
          
             "Ben Williams"  
                     
                     
 
             <Ben.Williams@tel  
                     
                    
             elogic.com>    
                     
                     To
             Sent by:      
           "Eclipse Process Framework
Project  
             epf-dev-bounces@e    
    Developers List"          
         
             clipse.org      
         <epf-dev@xxxxxxxxxxx>    
          
                    
                     
                     
       cc 
                    
                     
                     
          
             13 March 2007    
                     
              Subject 
             15:14 CET      
          RE: [epf-dev] Prioritizing    
     
                    
                  requirements
                     
 
                    
                     
                     
          
             Please respond to    
                     
                  
              Eclipse Process  
                     
                     
             Framework Project    
                     
                  
              Developers List  
                     
                     
             <epf-dev@eclipse.  
                     
                    
                   org>
                     
                     
       
                    
                     
                     
          
                    
                     
                     
          




As per previous mail I sent yesterday on the subject, I entirely agree
that
we need to make the Stakeholder the responsible actor for prioritization
of
requirements.

This is vital and we need to be explicit in this.

Should we provide guidance in effective prioritization techniques?

Should there be an explicit step in a task somewhere in the process that
deals with prioritization?
If so, where should that be? Plan Iteration is the logical place from the
current structure, but in reality, you will be capturing stakeholder
priorities during the requirements gathering phase, and subsequently
reviewing those priorities in the context of the rest of the requirements
at a later time.

Ben

> -----Original Message-----
> From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Scott W. Ambler
> Sent: 13 March 2007 12:48
> To: Eclipse Process Framework Project Developers List
> Subject: RE: [epf-dev] Prioritizing requirements
>
>
> On Tue, March 13, 2007 5:44 am, Mark.Dickson@xxxxxxxxx said:
> > Thanks Scott.
> >
> > Having spent some more time looking deeper into the content,
it looks
> to
> > me
> > like OpenUP/Basic handles prioritization of requirements in a
number
> of
> > places. I thought I'd share what I have found. Please chip in
if I
> have
> > misunderstood the approach.
> >
> > In the Requirements task Define Vision, we "Define features
of the
> system"
> > which includes "Work with stakeholders to capture a list
of features
> that
> > stakeholders want in the system, briefly describing them and
giving
> > attributes to help define their general status and priority in
the
> project
> > ."
> >
> > In the Task: Plan Project (perhaps not as big surprise...). The
PM
> "works
> > with the team" to map the work items list to time, introducing
the
> phase
> > milestones and deciding on how many iterations are required.
We
> outline
> > the
> > features targeted for each iteration "putting the top priority
work
> items
> > first." This is all done with a view to refining on each
iteration
> rather
> > than being set in stone predictive planning, naturally.
>
> I'm a bit worried about this wording.  We need to make it explicit
that
> stakeholders are responsible for prioritizing the requirements.
>
>
> >
> > In the PM task Plan Iteration, "The Role: Project Manager
works with
> the
> > rest of the team, and especially the project stakeholders, to
identify
> the
> > high-priority work items from the Artifact: Work Items List to
be
> > addressed
> > within the iteration."
>
> Sounds like the PM is responsible for prioritization in this wording.
> I'm
> not convinced that's the message we should be sending.
>
> >
> > That seems to define the general approach to prioritization as
it
> stands,
> > as far as I can see. At a project level, this seems to be feature-
> driven,
> > with the stakeholder defining the relative priority of the features.
>
> That's definitely what we want, but we need to ensure that it says
> exactly
> that.
>
> >
> > At an iteration level, "the team" (which should include
the
> Stakeholder)
> > decide the items from the work items list that need to be implemented,
> > working against the overall plan, phase objectives and the prioritized
> > feature set defined in the vision. (As an aside - there might
be some
> > questions arising from this about the relationship between a
"feature"
> and
> > an item on the work items list such as a scenario. Maybe those
> discussions
> > have already happened?)
>
> The definition of work item should address this issue, IMHO.  I
don't
> have
> easy access to EPF right now so can't verify.
>
> >
> > We are in the process of writing an architecture step called
"Identify
> > architecturally significant requirements." This will effectively
> define a
> > subset of the requirements that need to be delivered in order
to
> achieve
> > the Elaboration Phase milestone. The architectural priority of
> > requirements
> > should be a factored into the team discussion within "Plan
Project"
> and
> > "Plan Iteration" in determining the overall priority
on the Work Items
> > List. The implication being that the longer it takes to deliver
this
> > subset, then the longer it takes to get out of Elaboration and
into
> > Construction.
>
> Definitely.  A discussion of the relationship between business
> prioritization and architecturally-significant prioritization should
be
> included somewhere.  I've found that there is very often a direct
> co-relation between architecturally-significant and high-business
value,
> and that the reworking of the work item list shouldn't be significant
in
> most situations.
>
>
> >
> > Introducing this step should provide a means to balance the
> prioritization
> > of requirements to meet Stakeholder needs and achieving architectural
> > stability. From a purely architectural perspective, it also seems
more
> > explicitly collaborative than the stark "architect prioritizes
the use
> > cases" approach in RUP, which was often misunderstood to
mean
> "Architect
> > is
> > Planning King" (IMHO).
>
> Hard to argue with that.
>
> - Scott
> Practice Leader Agile Development, IBM Rational
> http://www-306.ibm.com/software/rational/bios/ambler.html
>
> Refactoring Databases (
> http://www.ambysoft.com/books/refactoringDatabases.html ) is now
> available.
>
> _______________________________________________
> epf-dev mailing list
> epf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epf-dev




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

Telelogic Lifecycle Solutions:
Helping You Define, Design & Deliver Advanced Systems & Software
Learn More at www.telelogic.com



Ben Williams
Product Manager, Lifecycle Solutions
Telelogic UK Ltd, Northbrook House, Oxford Science Park, Oxford, OX4 4GA,
United Kingdom
Phone: +44 (7710) 637 067
Fax: +44 (1865) 784 286
Mobile phone: +44 (7710) 637 067


Ben.Williams@xxxxxxxxxxxxx
http://www.telelogic.com


Telelogic - Requirements-Driven Innovation!
-------------------------------------------------------------








The information contained in this e-mail, including any attachment or
enclosure, is intended only for the person or entity to which it is
addressed and may contain confidential material. Any unauthorized use,
review, retransmissions, dissemination, copying or other use of this
information by persons or entities other than the intended recipient is
prohibited.


  _______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev





Whilst this email has been checked for all known viruses, recipients should
undertake their own virus checking as Xansa will not accept any liability
whatsoever.

This email and any files transmitted with it are confidential and protected
by client privilege.  It is solely for the use of the intended recipient.
Please delete it and notify the sender if you have received it in
error. Unauthorised use is prohibited.

Any opinions expressed in this email are those of the individual and not
necessarily the organisation.
     Xansa, Registered Office: 420 Thames Valley Park Drive,
     Thames Valley Park, Reading, RG6 1PU, UK.
     Registered in England No.1000954.
     t  +44 (0)8702 416181
     w  www.xansa.com
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev