Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [epf-dev] Prioritizing requirements

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.

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."

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.

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?)

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.

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).

All comments welcomed.

cheers

Mark




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


                                                                           
             "Scott W. Ambler"                                             
             <swa@xxxxxxxxxxxx                                             
             >                                                          To 
             Sent by:                  "Eclipse Process Framework Project  
             epf-dev-bounces@e         Developers List"                    
             clipse.org                <epf-dev@xxxxxxxxxxx>               
                                                                        cc 
                                                                           
             12 March 2007                                         Subject 
             18:19 EST                 RE: [epf-dev] Prioritizing          
                                       requirements                        
                                                                           
             Please respond to                                             
              Eclipse Process                                              
             Framework Project                                             
              Developers List                                              
             <epf-dev@eclipse.                                             
                   org>                                                    
                                                                           
                                                                           





On agile projects the stakeholders typically are responsible for
prioritization whereas the IT folks are responsible for estimation.  See
http://www.agilemodeling.com/essays/changeManagement.htm#PrioritizingRequirements

for some thoughts on this subject.

I'd be concerned if we deviated from this sort of approach.

- Scott

On Mon, March 12, 2007 11:12 am, Ben Williams said:
> Mark
>
>
>
> Well raised, I think this is an area that needs clarification.
>
>
>
> Maybe I'm having a bad sight day, but I'm in the same boat as you......
>
> First of all, I don't think there is any explicit mention of
> prioritizing requirements as an entity, but prioritizing items in the
> WIL (including requirements) is covered partially.
>
>
>
> Certainly the Project Manager, as primary performer of Task: 'Plan
> Iteration' uses the Stakeholder prioritization as a necessary input into
> that task, but the steps in the task itself could be interpreted in a
> couple of different ways.
>
>
>
> Note my highlighting in Red below.
>
>
>
>
> <file:///F:\Telelogic\Product%20Management\EPF\OpenUP_Basic_published-0.
> 9-W-20070216\Publish\openup_basic\tasks\plan_iteration,_0keUEMlgEdmt3adZ
> L5Dmdw.html> Define the iteration objectives
>
> At the beginning of an iteration, the Role: Project Manager
> <file:///F:\Telelogic\Product%20Management\EPF\OpenUP_Basic_published-0.
> 9-W-20070216\Publish\openup_basic\roles\project_manager,_0a0o0MlgEdmt3ad
> ZL5Dmdw.html>  works with the team to define 1-5 objectives. These
> objectives should be a refinement of the iteration objectives found in
> the Artifact: Project Plan
> <file:///F:\Telelogic\Product%20Management\EPF\OpenUP_Basic_published-0.
> 9-W-20070216\Publish\openup_basic\workproducts\project_plan,_0a6vcMlgEdm
> t3adZL5Dmdw.html> , and should provide high-level direction to what
> should be targeted for the iteration. The objectives should be driven
> based on Role: Stakeholder
> <file:///F:\Telelogic\Product%20Management\EPF\OpenUP_Basic_published-0.
> 9-W-20070216\Publish\openup_basic\roles\stakeholder,_dTa6gMAYEdqX-s4mWhk
> yqQ.html>  priorities, and will be revised as the iteration plan is
> finalized. The objectives are usually defined as high-level capabilities
> or scenarios that need to be implemented and tested during the
> iteration.
>
>
> <file:///F:\Telelogic\Product%20Management\EPF\OpenUP_Basic_published-0.
> 9-W-20070216\Publish\openup_basic\tasks\plan_iteration,_0keUEMlgEdmt3adZ
> L5Dmdw.html> Produce detailed plan
>
> The Role: Project Manager
> <file:///F:\Telelogic\Product%20Management\EPF\OpenUP_Basic_published-0.
> 9-W-20070216\Publish\openup_basic\roles\project_manager,_0a0o0MlgEdmt3ad
> ZL5Dmdw.html>  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
> <file:///F:\Telelogic\Product%20Management\EPF\OpenUP_Basic_published-0.
> 9-W-20070216\Publish\openup_basic\workproducts\work_items_list,_rGNWsCbS
> Edqh1LYUOGRh2A.html>  to be addressed within the iteration. The
> high-level objectives provide guidance on what work items should be
> considered. The team should break down work items so they fit within the
> iteration as necessary. Actual effort to complete each Work Item should
> be estimated. When a team has decided to take on a Work Item, it will
> assign the work to one or several team members. Ideally, this is done by
> team members signing up to do the work, since this makes people
> motivated and committed to doing the job, but based on culture, you may
> instead have the project manager assign the work.
>
>
>
> With the first step, it is ambiguous (to me at least) as to whether the
> prioritization has already occurred elsewhere or not.
>
>
>
> With the second step, it is implied that that the prioritization is
> happening here in this step (or why would we need to work with
> 'especially the project stakeholders'?)
>
>
>
> The following exists within Task: 'Define Vision':
>
>
>
>
> <file:///F:\Telelogic\Product%20Management\EPF\OpenUP_Basic_published-0.
> 9-W-20070216\Publish\openup_basic\tasks\define_vision,_0fOAoMlgEdmt3adZL
> 5Dmdw.html> Define features of the system
>
> Work with stakeholders to capture a list of features
> <file:///F:\Telelogic\Product%20Management\EPF\OpenUP_Basic_published-0.
> 9-W-20070216\Publish\openup_basic\guidances\termdefinitions\feature,_PgY
> REAeYEduWycDgioo5rg.html>  that stakeholders want in the system, briefly
> describing them and giving attributes to help define their general
> status and priority in the project.
>
>
>
> The Task: 'Find and Outline Requirements' contains:
>
>
>
>
> <file:///F:\Telelogic\Product%20Management\EPF\OpenUP_Basic_published-0.
> 9-W-20070216\Publish\openup_basic\tasks\find_and_outline_requirements,_P
> 9cMUPV_EdmdHa9MmVPgqQ.html> Update the Work Items List
>
> Capture references to the requirements in the Artifact: Work Items List
> <file:///F:\Telelogic\Product%20Management\EPF\OpenUP_Basic_published-0.
> 9-W-20070216\Publish\openup_basic\workproducts\work_items_list,_rGNWsCbS
> Edqh1LYUOGRh2A.html> , so that you can prioritize the work.
>
>
>
> The WIL artifact of course has the following Purpose field:
>
>
> <file:///F:\Telelogic\Product%20Management\EPF\OpenUP_Basic_published-0.
> 9-W-20070216\Publish\openup_basic\workproducts\work_items_list,_rGNWsCbS
> Edqh1LYUOGRh2A.html> Purpose
>
> To collect all requests for work that will potentially be taken on
> within the project, so work can be prioritized, effort estimated and
> progress tracked.
>
>
>
> And the following exists in the Main Description of the WIL artifact:
>
>
>
> *         It provides one list of all the work to be prioritized,
> estimated, and assigned within the project. The risk list is prioritized
> separately.
>
>
>
> In summary, I think prioritization of items in the WIL should be an
> explicit step somewhere (perhaps in 'Plan Iteration' ?), and other
> references to prioritization should be cleaned up.
>
>
>
> Ben
>
>
>
>
>
>> -----Original Message-----
>
>> From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx]
>
>> On Behalf Of Mark.Dickson@xxxxxxxxx
>
>> Sent: 12 March 2007 14:26
>
>> To: epf-dev@xxxxxxxxxxx
>
>> Subject: [epf-dev] Prioritizing requirements
>
>>
>
>> Quick question;
>
>>
>
>> Can someone tell me briefly where in OpenUP/Basic we describe
>
>> requirements
>
>> prioritization? Who is the primary performer and what Task is it
>
>> described
>
>> in? I've flipped though the obvious places in the content but I may
> have
>
>> missed it.
>
>>
>
>> Traditionally in the Unified Process it is something that the
> Architect
>
>> has
>
>> been responsible for within Requirements workflows, hence my interest.
>
>>
>
>> thanks
>
>>
>
>> Mark
>
>>
>
>> Mark Dickson
>
>> Executive Consultant
>
>> EAS Practice
>
>> m 0780 1917480
>
>> w www.xansa.com
>
>> e mark.dickson@xxxxxxxxx
>
>>
>
>>
>
>> 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
>
>
--------------------------------------------------------------------------------

> 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
>


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



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


Back to the top