| Terminating or Reprioritizing Iterations in OpenUP/Basic [message #22616] |
Tue, 07 November 2006 17:11  |
Eclipse User |
|
|
|
What should OpenUP recommend when an iteration is not likely to deliver
some incremental functionality? For instance, if the team falls too far
behind, a serious problem arises, or management demands an immediate
change in focus (implement different requirements than those chosen for
the iteration)?
We currently recommend re-prioritizing and adjusting the scope of the
current iteration (Task: Manage Iteration). One issue I can think of
with this is that it's not Scrum-like, which isn't an awful thing but
it's inconsistent with other areas of our PM discipline that draw from
Scrum. Reprioritization also won't necessarily lead to the delivery of
stable incremental functionality as the items in the current iteration
are already considered the top priority.
The current OpenUP review that's focusing on consistency recommends
changing this guidance and terminating the iteration instead. Then the
reprioritization and concurrance would occur as part of the new
iteration. This may have the advantage of starting an iteration with a
clean slate rather than trying to save an iteration that's doomed.
Another option is to suggest both as possible alternatives but endorse
one of those solutions. Then we need to ask ourselves if a team using
the process out-of-the-box has the experience to make the right choice.
Does anyone feel strongly about this, or have another alternative?
Jim Ruehlin
jruehlin@us.ibm.com
|
|
|
| Re: Terminating or Reprioritizing Iterations in OpenUP/Basic [message #23174 is a reply to message #22616] |
Fri, 10 November 2006 03:33  |
| Eclipse User |
|
|
|
Originally posted by: user.domain.invalid
The best approach in "real life" is to have iterations timeboxed.
Exceptions could be listed such as prolonging an iteration to reach
phase goals or to conclude testing.
A situation that is frequent in Construction is to have testing remain
while the next iteration starts. To have two iterations running is "no
crime" as long as PM has full control.
:) Göran Rehnlund
Jim Ruehlin wrote:
> What should OpenUP recommend when an iteration is not likely to deliver
> some incremental functionality? For instance, if the team falls too far
> behind, a serious problem arises, or management demands an immediate
> change in focus (implement different requirements than those chosen for
> the iteration)?
>
> We currently recommend re-prioritizing and adjusting the scope of the
> current iteration (Task: Manage Iteration). One issue I can think of
> with this is that it's not Scrum-like, which isn't an awful thing but
> it's inconsistent with other areas of our PM discipline that draw from
> Scrum. Reprioritization also won't necessarily lead to the delivery of
> stable incremental functionality as the items in the current iteration
> are already considered the top priority.
>
> The current OpenUP review that's focusing on consistency recommends
> changing this guidance and terminating the iteration instead. Then the
> reprioritization and concurrance would occur as part of the new
> iteration. This may have the advantage of starting an iteration with a
> clean slate rather than trying to save an iteration that's doomed.
>
> Another option is to suggest both as possible alternatives but endorse
> one of those solutions. Then we need to ask ourselves if a team using
> the process out-of-the-box has the experience to make the right choice.
>
> Does anyone feel strongly about this, or have another alternative?
>
> Jim Ruehlin
> jruehlin@us.ibm.com
>
|
|
|
| Re: Terminating or Reprioritizing Iterations in OpenUP/Basic [message #568055 is a reply to message #22616] |
Fri, 10 November 2006 03:33 |
| Eclipse User |
|
|
|
The best approach in "real life" is to have iterations timeboxed.
Exceptions could be listed such as prolonging an iteration to reach
phase goals or to conclude testing.
A situation that is frequent in Construction is to have testing remain
while the next iteration starts. To have two iterations running is "no
crime" as long as PM has full control.
:) Göran Rehnlund
Jim Ruehlin wrote:
> What should OpenUP recommend when an iteration is not likely to deliver
> some incremental functionality? For instance, if the team falls too far
> behind, a serious problem arises, or management demands an immediate
> change in focus (implement different requirements than those chosen for
> the iteration)?
>
> We currently recommend re-prioritizing and adjusting the scope of the
> current iteration (Task: Manage Iteration). One issue I can think of
> with this is that it's not Scrum-like, which isn't an awful thing but
> it's inconsistent with other areas of our PM discipline that draw from
> Scrum. Reprioritization also won't necessarily lead to the delivery of
> stable incremental functionality as the items in the current iteration
> are already considered the top priority.
>
> The current OpenUP review that's focusing on consistency recommends
> changing this guidance and terminating the iteration instead. Then the
> reprioritization and concurrance would occur as part of the new
> iteration. This may have the advantage of starting an iteration with a
> clean slate rather than trying to save an iteration that's doomed.
>
> Another option is to suggest both as possible alternatives but endorse
> one of those solutions. Then we need to ask ourselves if a team using
> the process out-of-the-box has the experience to make the right choice.
>
> Does anyone feel strongly about this, or have another alternative?
>
> Jim Ruehlin
> jruehlin@us.ibm.com
>
|
|
|
Powered by
FUDForum. Page generated in 0.06073 seconds
Home