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