[
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
|
OK,
so this is the consolidated vote results
so far. One X or Y for each vote,
X marks committer vote, Y marks contributor
vote. I marked with blue what are given choices based on votes so far.
Feels like there are two issues where
there are some disagreements:
A) Do we refer to "project level"
things as "Development" or "Project". Impacts Role
#1, Work Product #1, Report #1
B) Do we think that Work product #4
is a view of Work product #2 that is referenced from Work Product #3 or
a separate work product.
At least we have agreement on all issues
but those... So, looking forward to an interesting PM meeting today.
Votes by: Scott, Chris A, Mark, Pascal(Y), Per, Peter,
Steve, Ricardo, Jim, Bruce, Chris S, Ana (Y), Todd
Role #1: [XXY ] Development lead, [XXXXXXXYX ] Project
manager, [ ] Team lead, [ ]
Technical lead, [X ] Other: Process Engineer_______________
Work Product #1: [XXYX ] Development plan, [XXXXXXXXY
] Project plan, [ ] Release plan,
[ ] Other: _______________
Work Product #2: [XX ] Development item list, [ ]
Product backlog, [ ]
Development backlog, [
XXYXXXXX] Work item list, [ ] Release backlog,
[ ]
Cross-project backlog, [ ] System work item list,
[ ] Project work item
list, [Y ] Other: Feature Backlog_______________
Work Product #3: [XXXYXXXXXXXYX
] Iteration plan, [ ] Other: _______________
Work Product #4: [XYX ] Task list, [ ] Sprint backlog,
[ X] Work item list, [
] Team work item list, [X ] Iteration work item list,
[XXXXXXYX ] Other:
_______________; recommended representation of placing
this inside of Work
Product #3
Work Product #5: [
XXXYXXXXXXXYX] Risk list, [ ] Other: _______________
Work Product #6: [
XXXYXXXXXXXYX] Status assessment, [ ] Other:
_______________
Report #1: [XXYX ] Development burndown, [ ] Release
burndown, [XXXXXXXX ] Project
burndown, [ Y] Other: Feature Backlog_______________
Report #2: [XXXYXXXXXXXYX
] Iteration burndown, [ ] Sprint burndown,
[ ] Other:
_______________
Per Kroll
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM Corp
408-342-3815
Bruce Macisaac/Cupertino/IBM@IBMUS
Sent by: epf-dev-bounces@xxxxxxxxxxx
07/13/2006 11:54 AM
Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx> |
|
To
| chris.armstrong@xxxxxxxxxxxxxxxxx, Eclipse
Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| 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_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev