[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [epf-dev] Ballot for voting on PM process element names and next PM call
|
Hi All,
Below is my vote - but I think we need to
spend some time discussing number 4, which I've marked as not needed.
In Vancouver we had a long discussion about
whether there were 2 lists or 1 list of work items. Some of the motivations
for the 2 lists were:
a. Different audiences - one list is targetted
to the customer, the other to the development team.
b. Alignment to Scrum's product backlog and
sprint backlog.
c. Alignment to the coarse project plan and
iteration plan of RUP.
The problem with the 2 lists was mainly:
a. What to do with items that went on both
lists, like change requests and defects.
Since then, I have found another problem
with the 2 lists - I don't think 2 lists is enough.
Let's assume for the moment that there is
one thing called a work items list, that you can decompose into smaller
work items.
So what are the views of work items?
Here are a few:
1. Work items that deliver end-user value.
(This is of interest to the customer, and lower level decompositions
of these items for manging the work within the iteration are not of interest
to the customer). This is the product backlog.
1a. Subset of these items in
scope for the project (project backlog)
1b. Subset of these items in
scope for a release (release backlog)
1c. Subset of these items in
scope for an iteration (iteration backlog)
1d. Subset not in scope for
the project.
1e. Subset not allocated as
in or out of project scope (proposed work items list)
1f. Subsets by kind (defect,
supporting requirement, etc.)
2. Work items that deliver interim customer
deliverables. This might include creation of requirements documents,
gap analysis of COTS alternatives,
and architectural analysis.
3. Work items that need to be done for the
project to succeed, and need to be allocated to an iteration, but are not
of interest to the customer.
This is of interest to the project manager,
to determine what can be done in a given iteration.
This may include "overhead" work
that the customer doesn't care about, such as training, tool setup, determining
what resale potential there is to other customers, etc.
4. Work items for creating infrastructure
functionality, or reusable functionality, but doesn't by itself deliver
end-user functionality, or requires more investment than is needed by a
single customer.
5. Work items allocated to an iteration.
6. Work items decomposed to a level where
they are assignable to individuals for the current or next iteration (iteration
backlog)
7. Work items that are fixed overhead, such
as "managing the project", "maintaining the development
environment" etc.
8. Work items decomposed to where they are
assignable not to an individual, but to a subteam.
Some useful burndown charts are:
A. Burndown of (1). Agilists argue that this
is the real "progress" metric for the project.
B. Burndown of (1) and (2). This tells
the customer if we are delivering what they are asking for, and is close
to a traditional "earned value" approach.
This kind of burndown has its flaws, but I think some customers will want
to produce it.
C. Burndown of (1), (2), and (3). This
tells the project manager if the project work is tracking according to
plan.
D. Combinations of the above with items of
category (4) included in different ways.
E. Burndowns of (6) for the current iteration
only.
F. Burndowns of (6) for a given individual
or (8) for a team.
While we've been talking about 2 lists of
work items, and 2 burndown reports, I don't think we have made it clear
what goes in these 2 lists and 2 reports, and we have trouble describing
what to do about the overlap.
I think having one repository of work items,
with various reports or views of it, is clearer and more extensible.
I believe that the one repository approach
is how agile management tools tend to implement this kind of functionality
- perhaps someone who knows the specifics of these tools can confirm this.
I consider it important that we have a clear
story for how we map to Scrum, but rather than two work products, I think
two views on one work product can work just as well, and is more flexible.
We need to come up with names for the views
and/or burndown charts that we want to mandate for OpenUP, so that we can
clearly distinguish between
items of interest to specific roles.
I think we should describe the concept of
a product backlog, and define as (1), and the concept of an iteration backlog
(6) above, and have these as
fundamentally important views of the work
items list.
That said, some other views may also end
up being useful, such as the concept of an internal product backlog, that
includes work items that the customer doesn't care about, but the project
manager does care about, may also be useful when planning what work to
allocate to a given iteration.
Sorry to bring up the one list vs. two lists
again, but I hope that further discussion will be useful.
Ok - so here's my vote:
Role #1: [ ] Development lead, [X
] Project manager, [ ] Team lead,
[ ] Technical lead, [ ] Other:
Work Product #1: [ ] Development plan, [X
] Project plan, [ ] Release plan, [ ] Other: _______________
Work Product #2: [ ] Development item list,
[ ] Product backlog, [ ] Development backlog, [X
] Work item list, [ ] Release backlog, [ ] Cross-project backlog, [ ] System
work item list, [ ] Project work item list, [ ] Other: _______________
Work Product #3: [X
] Iteration plan, [ ] Other: _______________
Work Product #4: [] Task list, [ ] Sprint
backlog, [ ] Work item list, [ ] Team work item list, [ ] Iteration work
item list, [ X]
Other: _NOT NEEDED
______________; recommended representation of placing this
inside of Work Product #3
Work Product #5: [ X]
Risk list, [ ] Other: _______________
Work Product #6: [X
] Status assessment, [ ] Other: _______________
Report #1: [ ] Development burndown, [ ] Release
burndown, [ X]
Project burndown, [ ] Other: _______________
Report #2: [X
] Iteration burndown, [ ] Sprint burndown, [ ] Other: _______________
Bruce MacIsaac
Manager - RUP/OpenUP Content
bmacisaa@xxxxxxxxxx
phone: (408)863-8718
"Chris Armstrong"
<chris.armstrong@xxxxxxxxxxxxxxxxx>
Sent by: epf-dev-bounces@xxxxxxxxxxx
07/07/2006 10:18 AM
Please respond to
chris.armstrong@xxxxxxxxxxxxxxxxx; Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx> |
|
To
| "'Eclipse Process Framework Project
Developers List'" <epf-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| [epf-dev] Ballot for voting on PM process
element names and next PM call |
|
Here is the ballot for voting on PM process
element names. I attempted to include the various names people have suggested
for these things as choices. If there are any that I overlooked or if there
are new ones that people would like to suggest, feel free to write them
in under "Other". To cast your vote, reply to this email message,
copy me (chris.armstrong@xxxxxxxxxxxxxxxxx), and place an '"x"
in one of the boxes that precede each choice to indicate your vote for
each element. The voting closes at 12:00am Friday 7/14 which will allow
us to tally the votes and report the results at the next PM conference
call (scheduled for 8am PST Friday 7/14) and the epf-dev mail list.
============================================================
Role #1: [ ] Development lead, [ ] Project
manager, [ ] Team lead, [ ] Technical lead, [ ] Other: _______________
Work Product #1: [ ] Development plan, [ ]
Project plan, [ ] Release plan, [ ] Other: _______________
Work Product #2: [ ] Development item list,
[ ] Product backlog, [ ] Development backlog, [ ] Work item list, [ ] Release
backlog, [ ] Cross-project backlog, [ ] System work item list, [ ] Project
work item list, [ ] Other: _______________
Work Product #3: [ ] Iteration plan, [ ] Other:
_______________
Work Product #4: [ ] Task list, [ ] Sprint
backlog, [ ] Work item list, [ ] Team work item list, [ ] Iteration work
item list, [ ] Other: _______________; recommended representation of placing
this inside of Work Product #3
Work Product #5: [ ] Risk list, [ ] Other:
_______________
Work Product #6: [ ] Status assessment, [
] Other: _______________
Report #1: [ ] Development burndown, [ ] Release
burndown, [ ] Project burndown, [ ] Other: _______________
Report #2: [ ] Iteration burndown, [ ] Sprint
burndown, [ ] Other: _______________
============================================================
Thanks, Chris ~:|
Chris Armstrong ~:|
President
Armstrong Process Group, Inc.
651.491.5575 c
715.246.0383 f
www.aprocessgroup.com
"proven practical process"
Come see APG at:
---------------
Agile 2006 International Conference
Minneapolis, MN, July 23-28, 2006 - www.agile2006.com
---------------
14th IEEE International Requirements Engineering Conference
Minneapolis, MN, September 11-15, 2006 - www.re06.org
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev