Home » Archived » EPF » OpenUP Work Items List Question
| OpenUP Work Items List Question [message #31917] |
Wed, 02 May 2007 05:01  |
Eclipse User |
|
|
|
Originally posted by: werner.beroux.com
Hello,
After using OpenUP for some time there is a point that isn't so clear for
me: The priorities in the Work Items List. It is said that the priority
changes all the time and that the highest one are implemented in the next
iteration. Does it mean that as the iterations move on and on the lower
priorities items become higher and higher priority? So actually all the
implemented items will in the end be marked as "Closed" with a priority of
"Highest" or "High". Is it?
Werner
|
|
|
| Re: OpenUP Work Items List Question [message #32270 is a reply to message #31917] |
Mon, 07 May 2007 23:23  |
 Ricardo Balduino
Messages: 191
Registered: July 2009 |
Senior Member |
|
|
Werner,
Not necessarily.
The Work Items List (WIL) is the repository of requirements, enhancements
requests, change requests, bugs and such. The list exists to help you
capture everything that is needed (and wanted) for the system to be. Those
items are prioritized from technical and/or business value perspective.
The high priority items are agreed to by customer and team to be addressed
in a given iteration. As the iteration goes by, you *typically* don't change
the scope of the iteration, even if a higher priority item is added to the
WIL. Those newly added high priority items will be assigned to the next
iteration.
Towards the end of the project, the remaining items in the WIL may be medium
to low priority, and you don't need to change their priority to high in
order to assign them to later iterations. Of course, medium priority items
will take precedence of low priority ones.
I hope I addressed your question.
Now, since you said you've been using OpenUP for some time, it would be
interesting to hear if you had to adapt OpenUP in some way to run in your
project or are using as-is.
Hearing experiences from this community is always appreciated, so we can
improve OpenUP where needed.
Thanks,
Ricardo Balduino
IBM / EPF Committer
"Werner Beroux" <werner@beroux.com> wrote in message
news:f195uj$qp2$1@build.eclipse.org...
> Hello,
>
> After using OpenUP for some time there is a point that isn't so clear for
> me: The priorities in the Work Items List. It is said that the priority
> changes all the time and that the highest one are implemented in the next
> iteration. Does it mean that as the iterations move on and on the lower
> priorities items become higher and higher priority? So actually all the
> implemented items will in the end be marked as "Closed" with a priority of
> "Highest" or "High". Is it?
>
> Werner
>
|
|
|
| Re: OpenUP Work Items List Question [message #32690 is a reply to message #32270] |
Fri, 18 May 2007 16:20 |
| Eclipse User |
|
|
|
Originally posted by: werner.beroux.com
My concern was for the item done, not the remaining items. Just wondering
that, if I follow what you said, all the items that are done will then be in
WIL as "Closed" with a high priority. Like...
Let take an example:
BEFORE (iteration 0):
Item1 High New
Item2 Normal New
Item3 Normal New
Item4 Low New
Item5 Lowest New
AFTER (last iteration):
Item1 High Closed
Item2 High Closed
Item3 Highest Closed
Item4 High Closed
Item5 Low New <-- This one is one not done, left for further
improvements.
Is it correct? It may look stupid but I just found it a bit strange on the
first reading (and the priorities are not as well explained as the points
estimation).
Thank you,
Werner
"Ricardo Balduino" <balduino@us.ibm.com> a
|
|
|
| Re: OpenUP Work Items List Question [message #32725 is a reply to message #32690] |
Fri, 18 May 2007 21:16 |
Ricardo Balduino
Messages: 191
Registered: July 2009 |
Senior Member |
|
|
Werner,
The items that are done will be marked as Closed, but not necessarily marked
as High priority.
My take is that you have a mix of High, Medium and Low priority work items
in the WIL (and whatever intermediate levels you may need) *throughout* the
project. If you address all High priority items on the iteration N, you
don't have to move the remaining work items from Medium to High so they can
be addressed in iteration N+1.
At every iteration you prioritize the work items that will be part of next
iteration - and that may be the cause of confusion, because we may be
overloading the term "prioritize" here. My understanding is that "prioritize
work items at every iteration" means having stakeholders and team sitting
together and discussing what happens on the next iteration, based on
priority and customer value (team velocity also counts, which means there is
a limit of what can be assigned to an iteration). It doesn't necessarily
mean changing the priority attribute of the work item only, otherwise you
sure end up with a list of all work items with high priority - who can tell
what their original priorities were in the beggining of the project in case
you are trying to learn the lessons at project retrospective?
Anyway, this is how I understand it works. If the text in OpenUP is not
clear, we may need to revisit it. And we may be lacking a guideline on
prioritization of work items, as you pointed out.
Anyone else with a different perspective?
Regards,
Ricardo Balduino.
"Werner Beroux" <werner@beroux.com> wrote in message
news:f2kmrn$9mp$1@build.eclipse.org...
> My concern was for the item done, not the remaining items. Just wondering
> that, if I follow what you said, all the items that are done will then be
> in WIL as "Closed" with a high priority. Like...
>
>
>
> Let take an example:
>
> BEFORE (iteration 0):
>
> Item1 High New
>
> Item2 Normal New
>
> Item3 Normal New
>
> Item4 Low New
>
> Item5 Lowest New
>
>
>
> AFTER (last iteration):
>
> Item1 High Closed
>
> Item2 High Closed
>
> Item3 Highest Closed
>
> Item4 High Closed
>
> Item5 Low New <-- This one is one not done, left for further
> improvements.
>
>
>
> Is it correct? It may look stupid but I just found it a bit strange on the
> first reading (and the priorities are not as well explained as the points
> estimation).
>
>
>
> Thank you,
>
> Werner
>
>
>
> "Ricardo Balduino" <balduino@us.ibm.com> a
|
|
|
| Re: OpenUP Work Items List Question [message #32757 is a reply to message #32725] |
Sat, 19 May 2007 00:55 |
| Eclipse User |
|
|
|
Originally posted by: werner.beroux.com
Thank you again for your answer,
So in the end the priorities are like the original priorities but refined?
Still I'm not quiet sure to understand how they are defined. If it is in
absolute: The priority of an item is for the project at any time; or
relative: the priority is dependant of the current iteration.
As you said to make a retrospective it should be absolute. In that case in
the first iterations we deal with the items with high priorities, and in the
last iterations we would deal items that have low priorities (as all the
high priorities one should be done).
On the other side in the OpenUP published version it's written "As the
priority of these work items increase [...]" (see section Guideline: Work
Items List) meaning that they should be relative. If they are relative, in
the end all should be high priority as in the end the remaining elements are
the most important improvements left. This removes the easy retrospective
possibility (requires a CVS or similar).
What you said sounds a bit like a mix between absolute and relative which
makes it somehow an average of both. Logically it shouldn't be something in
between.
Werner
"Ricardo Balduino" <balduino@us.ibm.com> a
|
|
|
| Re: OpenUP Work Items List Question [message #32836 is a reply to message #32757] |
Fri, 18 May 2007 22:00 |
Ana Valente Pereira
Messages: 18
Registered: July 2009 |
Junior Member |
|
|
Yes ... there is a guideline for Prioritizing Work Items to be included
in the next release of OpenUP. Bellow is the bug number used for
discussion... I have already included there you coments from may 14...
maybe you can put your comments there to give more input to the people
working on it:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=165974
thanks
Ana
Werner Beroux wrote:
> Thank you again for your answer,
>
> So in the end the priorities are like the original priorities but refined?
> Still I'm not quiet sure to understand how they are defined. If it is in
> absolute: The priority of an item is for the project at any time; or
> relative: the priority is dependant of the current iteration.
>
> As you said to make a retrospective it should be absolute. In that case in
> the first iterations we deal with the items with high priorities, and in the
> last iterations we would deal items that have low priorities (as all the
> high priorities one should be done).
>
> On the other side in the OpenUP published version it's written "As the
> priority of these work items increase [...]" (see section Guideline: Work
> Items List) meaning that they should be relative. If they are relative, in
> the end all should be high priority as in the end the remaining elements are
> the most important improvements left. This removes the easy retrospective
> possibility (requires a CVS or similar).
>
> What you said sounds a bit like a mix between absolute and relative which
> makes it somehow an average of both. Logically it shouldn't be something in
> between.
>
> Werner
>
> "Ricardo Balduino" <balduino@us.ibm.com> a écrit dans le message de news:
> f2l53e$4hd$1@build.eclipse.org...
>
>>Werner,
>>
>>The items that are done will be marked as Closed, but not necessarily
>>marked as High priority.
>>My take is that you have a mix of High, Medium and Low priority work items
>>in the WIL (and whatever intermediate levels you may need) *throughout*
>>the project. If you address all High priority items on the iteration N,
>>you don't have to move the remaining work items from Medium to High so
>>they can be addressed in iteration N+1.
>>
>>At every iteration you prioritize the work items that will be part of next
>>iteration - and that may be the cause of confusion, because we may be
>>overloading the term "prioritize" here. My understanding is that
>>"prioritize work items at every iteration" means having stakeholders and
>>team sitting together and discussing what happens on the next iteration,
>>based on priority and customer value (team velocity also counts, which
>>means there is a limit of what can be assigned to an iteration). It
>>doesn't necessarily mean changing the priority attribute of the work item
>>only, otherwise you sure end up with a list of all work items with high
>>priority - who can tell what their original priorities were in the
>>beggining of the project in case you are trying to learn the lessons at
>>project retrospective?
>>
>>Anyway, this is how I understand it works. If the text in OpenUP is not
>>clear, we may need to revisit it. And we may be lacking a guideline on
>>prioritization of work items, as you pointed out.
>>Anyone else with a different perspective?
>>
>>Regards,
>>
>>Ricardo Balduino.
>>
>>"Werner Beroux" <werner@beroux.com> wrote in message
>>news:f2kmrn$9mp$1@build.eclipse.org...
>>
>>>My concern was for the item done, not the remaining items. Just wondering
>>>that, if I follow what you said, all the items that are done will then be
>>>in WIL as "Closed" with a high priority. Like...
>>>
>>>
>>>
>>>Let take an example:
>>>
>>>BEFORE (iteration 0):
>>>
>>> Item1 High New
>>>
>>> Item2 Normal New
>>>
>>> Item3 Normal New
>>>
>>> Item4 Low New
>>>
>>> Item5 Lowest New
>>>
>>>
>>>
>>>AFTER (last iteration):
>>>
>>> Item1 High Closed
>>>
>>> Item2 High Closed
>>>
>>> Item3 Highest Closed
>>>
>>> Item4 High Closed
>>>
>>> Item5 Low New <-- This one is one not done, left for further
>>>improvements.
>>>
>>>
>>>
>>>Is it correct? It may look stupid but I just found it a bit strange on
>>>the first reading (and the priorities are not as well explained as the
>>>points estimation).
>>>
>>>
>>>
>>>Thank you,
>>>
>>>Werner
>>>
>>>
>>>
>>>"Ricardo Balduino" <balduino@us.ibm.com> a écrit dans le message de news:
>>>f1ocd1$lrj$1@build.eclipse.org...
>>>
>>>>Werner,
>>>>
>>>>
>>>>
>>>>Not necessarily.
>>>>
>>>>
>>>>
>>>>The Work Items List (WIL) is the repository of requirements,
>>>>enhancements requests, change requests, bugs and such. The list exists
>>>>to help you capture everything that is needed (and wanted) for the
>>>>system to be. Those items are prioritized from technical and/or business
>>>>value perspective.
>>>>
>>>>The high priority items are agreed to by customer and team to be
>>>>addressed in a given iteration. As the iteration goes by, you
>>>>*typically* don't change the scope of the iteration, even if a higher
>>>>priority item is added to the WIL. Those newly added high priority items
>>>>will be assigned to the next iteration.
>>>>
>>>>Towards the end of the project, the remaining items in the WIL may be
>>>>medium to low priority, and you don't need to change their priority to
>>>>high in order to assign them to later iterations. Of course, medium
>>>>priority items will take precedence of low priority ones.
>>>>
>>>>
>>>>
>>>>I hope I addressed your question.
>>>>
>>>>
>>>>
>>>>Now, since you said you've been using OpenUP for some time, it would be
>>>>interesting to hear if you had to adapt OpenUP in some way to run in
>>>>your project or are using as-is.
>>>>
>>>>Hearing experiences from this community is always appreciated, so we can
>>>>improve OpenUP where needed.
>>>>
>>>>
>>>>
>>>>Thanks,
>>>>
>>>>
>>>>
>>>>Ricardo Balduino
>>>>
>>>>IBM / EPF Committer
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>"Werner Beroux" <werner@beroux.com> wrote in message
>>>>news:f195uj$qp2$1@build.eclipse.org...
>>>>
>>>>>Hello,
>>>>>
>>>>>After using OpenUP for some time there is a point that isn't so clear
>>>>>for me: The priorities in the Work Items List. It is said that the
>>>>>priority changes all the time and that the highest one are implemented
>>>>>in the next iteration. Does it mean that as the iterations move on and
>>>>>on the lower priorities items become higher and higher priority? So
>>>>>actually all the implemented items will in the end be marked as
>>>>>"Closed" with a priority of "Highest" or "High". Is it?
>>>>>
>>>>>Werner
>>>>>
>>>>
>>>>
>>>
>>
>
>
|
|
| |
| Re: OpenUP Work Items List Question [message #32905 is a reply to message #32836] |
Sat, 19 May 2007 10:15 |
Charles Edwards
Messages: 28
Registered: July 2009 |
Junior Member |
|
|
Hi all,
I think that one of the big drivers for deciding what and how to identify
priorities and weightings for what gets selected to be done in an iteration
comes in part from your **Risk Management process**, because as Risks
(uncertainties, opportunities and threats) come and go, they change the
dynamic of what is taken more seriously at a point in time on the project
than other items. Political quick wins, Unexpected changes from left of
field, etc.
I did a simple paper on a SCRUM like / Work Item list planning (in my
context for a team of Enterprise Architects but in principle the same). but
in having a quick scan through it I've notices that the Risk planning side
wasn't mentioned (I will update the paper to include this shortly).
See here
http://www.agileea.com/Whitepapers/2007-04-01-AEA_SCRUM_base d_EA_Planning_Process.pdf
Also I did a presentation on this at the TOGAF conferrence in Cape Town in
March and there is an animated view in the presentation of how I see it
working (mainly for major serious changes that arrive on the doorstep of the
team during the iteration) Start at slide 16 and work forward here:
http://www.processwave.net/Presentations/2007/pw2007-Togaf-P uttingThe%27Agile%27IntoAnEAProcess-V1.1.pdf
Hope it is of some help. I'd also appreciate it if you disagree with any of
it, so I can refine it.... (and I'll have a closer look at the OpenUP)
regards Charles
"Ana Valente Pereira" <apereira@whatever.pt> wrote in message
news:f2l7oi$grh$1@build.eclipse.org...
> Yes ... there is a guideline for Prioritizing Work Items to be included in
> the next release of OpenUP. Bellow is the bug number used for
> discussion... I have already included there you coments from may 14...
> maybe you can put your comments there to give more input to the people
> working on it:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=165974
>
> thanks
>
> Ana
>
> Werner Beroux wrote:
>> Thank you again for your answer,
>>
>> So in the end the priorities are like the original priorities but
>> refined? Still I'm not quiet sure to understand how they are defined. If
>> it is in absolute: The priority of an item is for the project at any
>> time; or relative: the priority is dependant of the current iteration.
>>
>> As you said to make a retrospective it should be absolute. In that case
>> in the first iterations we deal with the items with high priorities, and
>> in the last iterations we would deal items that have low priorities (as
>> all the high priorities one should be done).
>>
>> On the other side in the OpenUP published version it's written "As the
>> priority of these work items increase [...]" (see section Guideline: Work
>> Items List) meaning that they should be relative. If they are relative,
>> in the end all should be high priority as in the end the remaining
>> elements are the most important improvements left. This removes the easy
>> retrospective possibility (requires a CVS or similar).
>>
>> What you said sounds a bit like a mix between absolute and relative which
>> makes it somehow an average of both. Logically it shouldn't be something
>> in between.
>>
>> Werner
>>
>> "Ricardo Balduino" <balduino@us.ibm.com> a
|
|
|
| Re: OpenUP Work Items List Question [message #578194 is a reply to message #31917] |
Mon, 07 May 2007 23:23 |
Ricardo Balduino
Messages: 191
Registered: July 2009 |
Senior Member |
|
|
Werner,
Not necessarily.
The Work Items List (WIL) is the repository of requirements, enhancements
requests, change requests, bugs and such. The list exists to help you
capture everything that is needed (and wanted) for the system to be. Those
items are prioritized from technical and/or business value perspective.
The high priority items are agreed to by customer and team to be addressed
in a given iteration. As the iteration goes by, you *typically* don't change
the scope of the iteration, even if a higher priority item is added to the
WIL. Those newly added high priority items will be assigned to the next
iteration.
Towards the end of the project, the remaining items in the WIL may be medium
to low priority, and you don't need to change their priority to high in
order to assign them to later iterations. Of course, medium priority items
will take precedence of low priority ones.
I hope I addressed your question.
Now, since you said you've been using OpenUP for some time, it would be
interesting to hear if you had to adapt OpenUP in some way to run in your
project or are using as-is.
Hearing experiences from this community is always appreciated, so we can
improve OpenUP where needed.
Thanks,
Ricardo Balduino
IBM / EPF Committer
"Werner Beroux" <werner@beroux.com> wrote in message
news:f195uj$qp2$1@build.eclipse.org...
> Hello,
>
> After using OpenUP for some time there is a point that isn't so clear for
> me: The priorities in the Work Items List. It is said that the priority
> changes all the time and that the highest one are implemented in the next
> iteration. Does it mean that as the iterations move on and on the lower
> priorities items become higher and higher priority? So actually all the
> implemented items will in the end be marked as "Closed" with a priority of
> "Highest" or "High". Is it?
>
> Werner
>
|
|
|
| Re: OpenUP Work Items List Question [message #578479 is a reply to message #32270] |
Fri, 18 May 2007 16:20 |
| Eclipse User |
|
|
|
Originally posted by: werner.beroux.com
My concern was for the item done, not the remaining items. Just wondering
that, if I follow what you said, all the items that are done will then be in
WIL as "Closed" with a high priority. Like...
Let take an example:
BEFORE (iteration 0):
Item1 High New
Item2 Normal New
Item3 Normal New
Item4 Low New
Item5 Lowest New
AFTER (last iteration):
Item1 High Closed
Item2 High Closed
Item3 Highest Closed
Item4 High Closed
Item5 Low New <-- This one is one not done, left for further
improvements.
Is it correct? It may look stupid but I just found it a bit strange on the
first reading (and the priorities are not as well explained as the points
estimation).
Thank you,
Werner
"Ricardo Balduino" <balduino@us.ibm.com> a
|
|
|
| Re: OpenUP Work Items List Question [message #578501 is a reply to message #32690] |
Fri, 18 May 2007 21:16 |
Ricardo Balduino
Messages: 191
Registered: July 2009 |
Senior Member |
|
|
Werner,
The items that are done will be marked as Closed, but not necessarily marked
as High priority.
My take is that you have a mix of High, Medium and Low priority work items
in the WIL (and whatever intermediate levels you may need) *throughout* the
project. If you address all High priority items on the iteration N, you
don't have to move the remaining work items from Medium to High so they can
be addressed in iteration N+1.
At every iteration you prioritize the work items that will be part of next
iteration - and that may be the cause of confusion, because we may be
overloading the term "prioritize" here. My understanding is that "prioritize
work items at every iteration" means having stakeholders and team sitting
together and discussing what happens on the next iteration, based on
priority and customer value (team velocity also counts, which means there is
a limit of what can be assigned to an iteration). It doesn't necessarily
mean changing the priority attribute of the work item only, otherwise you
sure end up with a list of all work items with high priority - who can tell
what their original priorities were in the beggining of the project in case
you are trying to learn the lessons at project retrospective?
Anyway, this is how I understand it works. If the text in OpenUP is not
clear, we may need to revisit it. And we may be lacking a guideline on
prioritization of work items, as you pointed out.
Anyone else with a different perspective?
Regards,
Ricardo Balduino.
"Werner Beroux" <werner@beroux.com> wrote in message
news:f2kmrn$9mp$1@build.eclipse.org...
> My concern was for the item done, not the remaining items. Just wondering
> that, if I follow what you said, all the items that are done will then be
> in WIL as "Closed" with a high priority. Like...
>
>
>
> Let take an example:
>
> BEFORE (iteration 0):
>
> Item1 High New
>
> Item2 Normal New
>
> Item3 Normal New
>
> Item4 Low New
>
> Item5 Lowest New
>
>
>
> AFTER (last iteration):
>
> Item1 High Closed
>
> Item2 High Closed
>
> Item3 Highest Closed
>
> Item4 High Closed
>
> Item5 Low New <-- This one is one not done, left for further
> improvements.
>
>
>
> Is it correct? It may look stupid but I just found it a bit strange on the
> first reading (and the priorities are not as well explained as the points
> estimation).
>
>
>
> Thank you,
>
> Werner
>
>
>
> "Ricardo Balduino" <balduino@us.ibm.com> a
|
|
|
| Re: OpenUP Work Items List Question [message #578529 is a reply to message #32725] |
Sat, 19 May 2007 00:55 |
| Eclipse User |
|
|
|
Originally posted by: werner.beroux.com
Thank you again for your answer,
So in the end the priorities are like the original priorities but refined?
Still I'm not quiet sure to understand how they are defined. If it is in
absolute: The priority of an item is for the project at any time; or
relative: the priority is dependant of the current iteration.
As you said to make a retrospective it should be absolute. In that case in
the first iterations we deal with the items with high priorities, and in the
last iterations we would deal items that have low priorities (as all the
high priorities one should be done).
On the other side in the OpenUP published version it's written "As the
priority of these work items increase [...]" (see section Guideline: Work
Items List) meaning that they should be relative. If they are relative, in
the end all should be high priority as in the end the remaining elements are
the most important improvements left. This removes the easy retrospective
possibility (requires a CVS or similar).
What you said sounds a bit like a mix between absolute and relative which
makes it somehow an average of both. Logically it shouldn't be something in
between.
Werner
"Ricardo Balduino" <balduino@us.ibm.com> a
|
|
|
| Re: OpenUP Work Items List Question [message #578551 is a reply to message #32757] |
Fri, 18 May 2007 22:00 |
Ana Valente Pereira
Messages: 18
Registered: July 2009 |
Junior Member |
|
|
Yes ... there is a guideline for Prioritizing Work Items to be included
in the next release of OpenUP. Bellow is the bug number used for
discussion... I have already included there you coments from may 14...
maybe you can put your comments there to give more input to the people
working on it:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=165974
thanks
Ana
Werner Beroux wrote:
> Thank you again for your answer,
>
> So in the end the priorities are like the original priorities but refined?
> Still I'm not quiet sure to understand how they are defined. If it is in
> absolute: The priority of an item is for the project at any time; or
> relative: the priority is dependant of the current iteration.
>
> As you said to make a retrospective it should be absolute. In that case in
> the first iterations we deal with the items with high priorities, and in the
> last iterations we would deal items that have low priorities (as all the
> high priorities one should be done).
>
> On the other side in the OpenUP published version it's written "As the
> priority of these work items increase [...]" (see section Guideline: Work
> Items List) meaning that they should be relative. If they are relative, in
> the end all should be high priority as in the end the remaining elements are
> the most important improvements left. This removes the easy retrospective
> possibility (requires a CVS or similar).
>
> What you said sounds a bit like a mix between absolute and relative which
> makes it somehow an average of both. Logically it shouldn't be something in
> between.
>
> Werner
>
> "Ricardo Balduino" <balduino@us.ibm.com> a écrit dans le message de news:
> f2l53e$4hd$1@build.eclipse.org...
>
>>Werner,
>>
>>The items that are done will be marked as Closed, but not necessarily
>>marked as High priority.
>>My take is that you have a mix of High, Medium and Low priority work items
>>in the WIL (and whatever intermediate levels you may need) *throughout*
>>the project. If you address all High priority items on the iteration N,
>>you don't have to move the remaining work items from Medium to High so
>>they can be addressed in iteration N+1.
>>
>>At every iteration you prioritize the work items that will be part of next
>>iteration - and that may be the cause of confusion, because we may be
>>overloading the term "prioritize" here. My understanding is that
>>"prioritize work items at every iteration" means having stakeholders and
>>team sitting together and discussing what happens on the next iteration,
>>based on priority and customer value (team velocity also counts, which
>>means there is a limit of what can be assigned to an iteration). It
>>doesn't necessarily mean changing the priority attribute of the work item
>>only, otherwise you sure end up with a list of all work items with high
>>priority - who can tell what their original priorities were in the
>>beggining of the project in case you are trying to learn the lessons at
>>project retrospective?
>>
>>Anyway, this is how I understand it works. If the text in OpenUP is not
>>clear, we may need to revisit it. And we may be lacking a guideline on
>>prioritization of work items, as you pointed out.
>>Anyone else with a different perspective?
>>
>>Regards,
>>
>>Ricardo Balduino.
>>
>>"Werner Beroux" <werner@beroux.com> wrote in message
>>news:f2kmrn$9mp$1@build.eclipse.org...
>>
>>>My concern was for the item done, not the remaining items. Just wondering
>>>that, if I follow what you said, all the items that are done will then be
>>>in WIL as "Closed" with a high priority. Like...
>>>
>>>
>>>
>>>Let take an example:
>>>
>>>BEFORE (iteration 0):
>>>
>>> Item1 High New
>>>
>>> Item2 Normal New
>>>
>>> Item3 Normal New
>>>
>>> Item4 Low New
>>>
>>> Item5 Lowest New
>>>
>>>
>>>
>>>AFTER (last iteration):
>>>
>>> Item1 High Closed
>>>
>>> Item2 High Closed
>>>
>>> Item3 Highest Closed
>>>
>>> Item4 High Closed
>>>
>>> Item5 Low New <-- This one is one not done, left for further
>>>improvements.
>>>
>>>
>>>
>>>Is it correct? It may look stupid but I just found it a bit strange on
>>>the first reading (and the priorities are not as well explained as the
>>>points estimation).
>>>
>>>
>>>
>>>Thank you,
>>>
>>>Werner
>>>
>>>
>>>
>>>"Ricardo Balduino" <balduino@us.ibm.com> a écrit dans le message de news:
>>>f1ocd1$lrj$1@build.eclipse.org...
>>>
>>>>Werner,
>>>>
>>>>
>>>>
>>>>Not necessarily.
>>>>
>>>>
>>>>
>>>>The Work Items List (WIL) is the repository of requirements,
>>>>enhancements requests, change requests, bugs and such. The list exists
>>>>to help you capture everything that is needed (and wanted) for the
>>>>system to be. Those items are prioritized from technical and/or business
>>>>value perspective.
>>>>
>>>>The high priority items are agreed to by customer and team to be
>>>>addressed in a given iteration. As the iteration goes by, you
>>>>*typically* don't change the scope of the iteration, even if a higher
>>>>priority item is added to the WIL. Those newly added high priority items
>>>>will be assigned to the next iteration.
>>>>
>>>>Towards the end of the project, the remaining items in the WIL may be
>>>>medium to low priority, and you don't need to change their priority to
>>>>high in order to assign them to later iterations. Of course, medium
>>>>priority items will take precedence of low priority ones.
>>>>
>>>>
>>>>
>>>>I hope I addressed your question.
>>>>
>>>>
>>>>
>>>>Now, since you said you've been using OpenUP for some time, it would be
>>>>interesting to hear if you had to adapt OpenUP in some way to run in
>>>>your project or are using as-is.
>>>>
>>>>Hearing experiences from this community is always appreciated, so we can
>>>>improve OpenUP where needed.
>>>>
>>>>
>>>>
>>>>Thanks,
>>>>
>>>>
>>>>
>>>>Ricardo Balduino
>>>>
>>>>IBM / EPF Committer
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>"Werner Beroux" <werner@beroux.com> wrote in message
>>>>news:f195uj$qp2$1@build.eclipse.org...
>>>>
>>>>>Hello,
>>>>>
>>>>>After using OpenUP for some time there is a point that isn't so clear
>>>>>for me: The priorities in the Work Items List. It is said that the
>>>>>priority changes all the time and that the highest one are implemented
>>>>>in the next iteration. Does it mean that as the iterations move on and
>>>>>on the lower priorities items become higher and higher priority? So
>>>>>actually all the implemented items will in the end be marked as
>>>>>"Closed" with a priority of "Highest" or "High". Is it?
>>>>>
>>>>>Werner
>>>>>
>>>>
>>>>
>>>
>>
>
>
|
|
| |
| Re: OpenUP Work Items List Question [message #578600 is a reply to message #32836] |
Sat, 19 May 2007 10:15 |
Charles Edwards
Messages: 28
Registered: July 2009 |
Junior Member |
|
|
Hi all,
I think that one of the big drivers for deciding what and how to identify
priorities and weightings for what gets selected to be done in an iteration
comes in part from your **Risk Management process**, because as Risks
(uncertainties, opportunities and threats) come and go, they change the
dynamic of what is taken more seriously at a point in time on the project
than other items. Political quick wins, Unexpected changes from left of
field, etc.
I did a simple paper on a SCRUM like / Work Item list planning (in my
context for a team of Enterprise Architects but in principle the same). but
in having a quick scan through it I've notices that the Risk planning side
wasn't mentioned (I will update the paper to include this shortly).
See here
http://www.agileea.com/Whitepapers/2007-04-01-AEA_SCRUM_base d_EA_Planning_Process.pdf
Also I did a presentation on this at the TOGAF conferrence in Cape Town in
March and there is an animated view in the presentation of how I see it
working (mainly for major serious changes that arrive on the doorstep of the
team during the iteration) Start at slide 16 and work forward here:
http://www.processwave.net/Presentations/2007/pw2007-Togaf-P uttingThe%27Agile%27IntoAnEAProcess-V1.1.pdf
Hope it is of some help. I'd also appreciate it if you disagree with any of
it, so I can refine it.... (and I'll have a closer look at the OpenUP)
regards Charles
"Ana Valente Pereira" <apereira@whatever.pt> wrote in message
news:f2l7oi$grh$1@build.eclipse.org...
> Yes ... there is a guideline for Prioritizing Work Items to be included in
> the next release of OpenUP. Bellow is the bug number used for
> discussion... I have already included there you coments from may 14...
> maybe you can put your comments there to give more input to the people
> working on it:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=165974
>
> thanks
>
> Ana
>
> Werner Beroux wrote:
>> Thank you again for your answer,
>>
>> So in the end the priorities are like the original priorities but
>> refined? Still I'm not quiet sure to understand how they are defined. If
>> it is in absolute: The priority of an item is for the project at any
>> time; or relative: the priority is dependant of the current iteration.
>>
>> As you said to make a retrospective it should be absolute. In that case
>> in the first iterations we deal with the items with high priorities, and
>> in the last iterations we would deal items that have low priorities (as
>> all the high priorities one should be done).
>>
>> On the other side in the OpenUP published version it's written "As the
>> priority of these work items increase [...]" (see section Guideline: Work
>> Items List) meaning that they should be relative. If they are relative,
>> in the end all should be high priority as in the end the remaining
>> elements are the most important improvements left. This removes the easy
>> retrospective possibility (requires a CVS or similar).
>>
>> What you said sounds a bit like a mix between absolute and relative which
>> makes it somehow an average of both. Logically it shouldn't be something
>> in between.
>>
>> Werner
>>
>> "Ricardo Balduino" <balduino@us.ibm.com> a
|
|
|
Goto Forum:
Current Time: Thu Apr 25 05:29:47 GMT 2024
Powered by FUDForum. Page generated in 0.03860 seconds |
] 
Search
Help
Register
Login
Home
