[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