| [epf-dev] PM burndown |
I finally got around to putting all PM elements and Bugzilla items in the burndown workbook. There are a number of new items that I've just added to Bugzilla to represent all PM work itms. I moved the four PM capability pattern items from General to PM (which seems to fall in line with the other capability patterns that are related to specific content areas). I actually created a new version of the PM tab to incorporate the updates regarding points, assigned iteration, and rollup/burndown. However, I don't think the burndown chart is using PM data and I think there are some formulas and formatting missing. Joe, I'm hoping you'll be able to help us through those issues. We need to review the allocation of work items to iterations and discuss the points estimation.
A couple of observations as it relates to OpenUP PM process and some miscellaneous comments...
- There are apparently links to another workbook in this workbook. When I open it up, I get a message that it contains links to other data sources. When I do an Edit-Links, it says there is a reference to Burndown_pkr.xls (Per?)….
- There is no reference to whom each element is assigned to and the amount of effort expected (on a weekly basis) to complete each element (i.e. tasks with assignments and time estimates). However, as I mentioned in the last PM call, one could infer work had been done within an iteration by each item's state changes (and presumably more relevantly measure "true" iteration burndown).
- Horizontal scale of project burndown charts should be shown at the iteration level, not the week level
- Horizontal scale of iteration burndown should be weeks within each iteration. However, since we are not estimating and tracking time, we really can't measure iteration burndown. We can show project burndown within each iteration (which is really an "interim" report on mid-iteration project burndown).
- Looks like iteration burndown chart is backwards (burn up?)
- Really should not allocate a single item to more that one iteration. An item must be able to be delivered in its entirety within a single iteration. This relates to the practice of decomposing an item into smaller-grained items that are sized appropriately for the iteration (and its schedule and resource). In context to OpenUP PM stuff, I'm struggling with how to represent the ongoing dialogue (and work) related to the PM lists and plans. Basically, the PM team has been solely focusing on addressing a single Bugzilla entry (#137120) for the last two iterations and it continues into the current iteration (M5). I suppose what really should have happened is this item should have been (and of course still could be) broken down into more fine grained items. I'd suggest that we attempted to "finish" those more fine-grained items, but then raised new items (change requests, defects, new requirements) which would have been the basis for ongoing planning and reporting.
- The spreadsheet does not incorporate a column to describe its priority
- The tab for each content area probably should have at least one item for every process element in the content area, even if there are not any Bugzilla entries for it (so we can prove that all requirements have been met). Actually, in taking a quick glance the other content area tabs, it looks like this might already be the case (can other owners confirm this?).
- There don't appear to be any entries for defining the delivery process. It seems to me that one item is not sufficient for this very large thing. Perhaps it could be decomposed into smaller items such as:
- OpenUP/Basic delivery process description
- Work breakdown structure
- Iteration activity diagrams (4)
- Individual items for overriding specific method content
- Probably need another general item for the method plug in itself
- Probably need yet another general item for the configuration
- One item for each view?
- What about items for standard and custom categories?
- Seems like it will be cumbersome to have to manually inspect Bugzilla and the burndown to see if they are consistent with one another. Maybe this is more of an issue when one is initially populating the list (like I'm doing) and perhaps not as much an issue on an ongoing basis.
Talk with y'all soon… 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
Attachment:
EPF_Burndown_20060719_ca.xls
Description: MS-Excel spreadsheet