RE: [epf-dev] Prioritizing requirements

["Brian Lyons" <blyons@xxxxxxxxxxxxx>]

hiho,

We should definitely ensure that it is clear that the stakeholder is the
one who prioritizes.  I think that was our intention, but Scott is right
that the exact words might imply otherwise.  Note that when we added in
the Stakeholder role, we decided we would not delegate responsibility at
the task level to that role -- so the authority in prioritization will
be rendered as supporting participation in these other tasks.

I have always used the word "priority" for business priority (i.e. from
the stakeholder) and "architectural significance" rather than
"architectural priority" for what the architect will specify.  Using the
word "priority" in only one context can reduce confusion.

It sounds like there is coverage of prioritization in all the right
places.  We just need to tweak the wording to ensure we are
communicating what we mean.  And I think a brief concept on prioritizing
requirements that remarks on ordering them in multiple dimensions
(business, architectural) would be good.  It can be an "aha" moment and
is something of a differentiator of the Unified Process when you explain
that you scope a release based on business priority, you attack risk by
front-loading the architecturally significant items, then when the
architecture has stabilized you build the rest of the functionality on
the proven framework in order of business priority.

                             --------- b
-----Original Message-----
From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Scott W. Ambler
Sent: Tuesday, March 13, 2007 8:48 AM
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