[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [epf-dev] Prioritizing requirements
|
Scott
On the point about features and work items,
a Work Item is defined as "Scheduled work to be done within the project" in
the Glossary.
The Guideline for Work Items List also says;
"A Work Item may represent work associated with a defect, enhancement
request, use case, scenario, user story, supporting requirement, or
anything else that captures a potential requirement or improvement to your
system. A Work Item may reference any type of requirement, defect,
enhancement request, or other useful information guiding you in what needs
to be done."
and
"Some of the work items may still be poorly defined, representing a big
chunk of work requiring potentially several staff months of effort. As the
priority of these work items increase, they are typically decomposed into
smaller work items that represent specific and well-defined tasks that may
take hours or days to address."
I would take from this that features are big chunks of Requirements that
are on the Work Items list in Inception that get broken down into
well-defined tasks over time.
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
13 March 2007 Subject
07:48 EST RE: [epf-dev] Prioritizing
requirements
Please respond to
Eclipse Process
Framework Project
Developers List
<epf-dev@eclipse.
org>
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
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
