Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.



Back to the top