[
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
|
Title: Ballot for voting on PM process element names and next PM call
Here are my votes (and comments)... Chris
~:|
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: [ x ] Development lead, [ ] Project
manager, [ ] Team lead, [ ] Technical lead, [ ] Other: _______________
Work Product #1: [ x ] Development
plan, [ ] Project plan, [ ] Release plan, [ ] Other: _______________
Work Product #2: [ x ] 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: [ x ] Iteration
plan, [ ] Other: _______________
Work Product #4: [ x ] 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
I respectfully disagree with Per's and Peter's comments (big
surprise, huh?). Without going into all the details right now, I'd like to
suggest that there is significant difference between planning and tracking what
product capabilities need to be delivered (development backlog) and measuring
ongoing requirements coverage (development burndown) versus planning and
tracking what activities the team is performing to deliver those capabilities
(task list) and measuring the expenditures of effort during an iteration
(iteration burndown). I think mushing these two things together is not the
appropriate approach as they really are fundamentally different things. We
should also consider that a small project may do much of this planning and
tracking with index cards (instead of fancy Word templates, Excel spreadsheets,
and Bugzilla) -- one set of cards for development items and one set of cards for
tasks seems reasonable (and is the approach described by many agile processes
including Scrum, Cohn's agile estimating and planning approach, and
XP).
Work Product #5: [ x ] Risk list, [
] Other: _______________
Work Product #6: [ x ] Status
assessment, [ ] Other: _______________
Report #1: [ x ] Development burndown, [ ] Release
burndown, [ ] Project burndown, [ ] Other: _______________
Report #2: [ x ] 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